GO is not a T-SQL command processed by the SQL Server engine. Instead, it is a batch separator that client tools such as SQL Server Management Studio (SSMS), sqlcmd, and Azure Data Studio interpret. When the tool encounters GO, it sends all statements collected since the previous GO (or start of the script) to the server as a single batch. Each batch is compiled separately, so variables declared after a GO are out of scope for subsequent batches, and certain statements (CREATE PROCEDURE, CREATE VIEW, etc.) must be the first in their batch. An optional integer can follow GO (e.g., GO 5). The tool will resend the preceding batch that many times. GO cannot appear inside strings, multi-statement functions, or stored-procedure bodies. In those contexts use semicolons or BEGIN…END blocks instead. Because GO is client-side, scripts executed through APIs (ADO.NET, JDBC, etc.) must omit it or split the text manually.
count
(INT) - Optional. Positive integer that repeats execution of the immediately preceding batch the specified number of times.Batches, Semicolon statement terminator, BEGIN…END, sqlcmd, SSMS, Variable scope
Sybase SQL Server 4.x (late 1980s)
No. GO is interpreted by client utilities like SSMS and sqlcmd and never reaches the SQL Server engine.
Only when you want to start a new batch. Use semicolons for normal statement termination.
Variables live only for the duration of the batch. A GO ends the batch, so variables declared before it are discarded.
Add an integer after GO, for example `GO 5`, to resend the preceding batch five times.