GO不是SQL关键字。

它是客户端工具(如SSMS)使用的批处理分隔符，用于将整个脚本分解为批处理

之前回答过几次…示例1

Use herDatabase
GO ; 

代码表示执行GO标记上面的指令。 我的默认数据库是myDatabase，所以不是使用myDatabase GO，并使当前查询使用她的数据库

tldr;在大多数情况下，围棋是IMO可选的。在大型事务批处理中使用GO是最好的，在这种情况下，您可以将许多不同的脚本一起编译在一个大型脚本中，并且不希望在使用类似变量时出现错误，以便在需要时将部分事务提交给服务器，而不是由于错误而回滚所有脚本。

LARGE TRANSACTION 1——>运行成功

去,——>在服务器中

LARGE TRANSACTION 2——>运行成功

去,——>在服务器中

LARGE TRANSACTION 3—>错误

去,如果没有其他GO语句，这将回滚事务1和事务2

不确定最好的方式来提供这个如此明智，但我确实觉得我读到的东西并没有真正地总结一切，包括我遇到的一个例子。

如前所述，GO只是向服务器“提交”一批命令。

我认为理解会话还有助于理解GO语句的必要性(或可选性)。

(这是我的技术细节可能会失败的地方，但社区会指出来，我们可以让这个答案更好)

通常，开发人员在单个会话中工作，通常只对数据库执行简单的语句。在这种情况下，GO是可选的，真的……人们只会把它扔在语句的末尾。

Jamshaid k给出的一个选项可能更有帮助，在这个选项中，您希望依次提交许多大型事务，而不是在其中一个事务失败时回滚所有事务。

在另一个场景中，这也很有用(这是我经历过的唯一一个场景)，许多小事务被编译成一个大脚本。例如

开发人员1制作脚本1

Dev 2制作脚本2

开发人员1制作脚本3

为了部署它们，需要编写一个python脚本来组合这些脚本，即script Master = script1 + script 2 + script 3。

这3个脚本中需要GO语句，否则脚本使用冲突变量时可能会出现错误，或者如果脚本3失败，脚本1和脚本2中的事务将回滚。

现在，考虑到目前的CI/CD解决方案，这个过程可能已经过时了，但这可能是另一种情况，我可以看到GO是有帮助的/预期的。

它是一个批处理终止符，但是你可以将它更改为任何你想要的

GO不是SQL关键字。

它是客户端工具(如SSMS)使用的批处理分隔符，用于将整个脚本分解为批处理

之前回答过几次…示例1

当我想在进入其他查询之前提交一组查询时，我使用GO关键字。

我可以补充的一点是，当你在GO命令之前声明了一些变量时，你将无法在GO命令之后访问这些变量。即

DECLARE @dt DateTime = GETDATE();
UPDATE MyTable SET UpdatedOn = @dt where mycondition = 'myvalue';
GO

-- Below query will raise an error saying the @dt is not declared.
UPDATE MySecondTable SET UpdatedOn = @dt where mycondition = 'myvalue'; -- Must declare the scalar variable "@dt".
GO

更新

我知道，人们询问什么时候使用Go命令，所以我想，我应该在我的查询中添加为什么我使用Go命令。

当我在表中有大量更新时，我通常在下班时运行这些更新(这意味着，我不会监视查询)，因为第二天很方便，可以发现表已经为其他操作做好了准备。

当我需要运行长时间的操作，并希望分离查询和完成部分事务时，我使用Go命令，例如:

-- First Query
Update MyBigTable1 SET somecol1='someval1' where somecol2='someval2'
GO
-- Second Query
Update MyBigTable2 SET somecol1='someval1' where somecol2='someval2'
GO
-- Third Query
Update MyBigTable3 SET somecol1='someval1' where somecol2='someval2'

执行上述查询将单独提交修改，而不会导致生成大量的回滚日志。另外，如果第三个查询失败，您知道前两个查询是正确执行的，并且不会回滚任何东西。因此，您不需要花费更多的时间为以前执行的查询再次更新/删除记录。

用一句话来总结，“我使用GO命令作为电子游戏中的检查点。”如果你在检查点(GO命令)后失败，你不需要重新开始，而是让你的游戏从最后一个检查点开始。