GO Após cada instrução T-SQL

Antes de responder quando usá-lo e por que, é primordial entender exatamente o que GOé e o que não é.

A palavra-chave GOé usada pelo SQL Server Management Studio e SQLCMD para significar uma coisa e apenas uma coisa: O fim de um lote de instruções. Na verdade, você pode até alterar o que usa para encerrar lotes para algo diferente de "GO":

Essa captura de tela acima é uma opção configurável no SSMS.

Mas o que é um lote?? Esta referência BOL diz melhor:

Um lote é um grupo de uma ou mais instruções Transact-SQL enviadas ao mesmo tempo de um aplicativo para o SQL Server para execução.

Simples assim. É apenas uma maneira personalizada de um aplicativo (sim... um aplicativo) enviar instruções para o SQL Server. Vamos ver um exemplo de aparência de aplicativo disso. Usarei o PowerShell para imitar o que um aplicativo faria para enviar instruções e lotes para o SQL Server:

$ConnectionString = "data source = SomeSQLInstance; initial catalog = AdventureWorks2012; trusted_connection = true; application name = BatchTesting;"

try {
    $SqlConnection = New-Object System.Data.SqlClient.SqlConnection($ConnectionString)
    $SqlCmd = New-Object System.Data.SqlClient.SqlCommand
    $SqlCmd.Connection = $SqlConnection

    # first batch of statements
    #
    $SqlCmd.CommandText = "
        select * from humanresources.department where departmentid = 1;
        select * from humanresources.department where departmentid = 2;
        select * from humanresources.department where departmentid = 3;
        select * from humanresources.department where departmentid = 4;"

    # execute the first batch
    #
    $SqlConnection.Open()
    $SqlCmd.ExecuteNonQuery()
    $SqlConnection.Close()

    # second batch of statements
    #
    $SqlCmd.CommandText = "
        select * from humanresources.department where departmentid = 5;
        select * from humanresources.department where departmentid = 6;
        select * from humanresources.department where departmentid = 7;
        select * from humanresources.department where departmentid = 8;"

    # execute the second batch
    #
    $SqlConnection.Open()
    $SqlCmd.ExecuteNonQuery()
    $SqlConnection.Close()
}
catch {
    $SqlCmd.Dispose()
    $SqlConnection.Dispose()
    Write-Error $_.Exception
}

Os comentários revelam, mas você pode ver acima que estamos enviando dois lotes programaticamente para o SQL Server. Vamos verificar isso, no entanto. Minha escolha aqui é usar Eventos Estendidos:

create event session BatchTesting
on server
add event sqlserver.sql_batch_starting
(
    set
        collect_batch_text = 1
    where
    (
        sqlserver.client_app_name = N'BatchTesting'
    )
),
add event sqlserver.sql_batch_completed
(
    set
        collect_batch_text = 1
    where
    (
        sqlserver.client_app_name = N'BatchTesting'
    )
),
add event sqlserver.sql_statement_starting
(
    set
        collect_statement = 1
    where
    (
        sqlserver.client_app_name = N'BatchTesting'
    )
),
add event sqlserver.sql_statement_completed
(
    set
        collect_statement = 1
    where
    (
        sqlserver.client_app_name = N'BatchTesting'
    )
)
add target package0.event_file
(
    set
        filename = N'<MyXelLocation>\BatchTesting.xel'
);
go

alter event session BatchTesting
on server
state = start;
go

Tudo o que essa sessão de XEvents está fazendo é capturar as instruções e lotes que iniciam e são concluídos de um aplicativo chamado "BatchTesting"(se você observar minha string de conexão no exemplo de código do PowerShell, é uma maneira rápida de examinar um originador específico de eventos usando o "application name" parâmetro de string de conexão e filtrando isso).

Depois de executar o código do PowerShell para enviar esses lotes e instruções, vejo os seguintes resultados:

Como você pode ver na captura de tela, fica claro como as instruções são divididas em dois lotes diferentes, também evidente pelos meios que usamos para chamar os lotes. E se olharmos na batch_textprimeira ocorrência de sql_batch_starting, podemos ver todas as instruções incluídas nesse lote:

    select * from humanresources.department where departmentid = 1;
    select * from humanresources.department where departmentid = 2;
    select * from humanresources.department where departmentid = 3;
    select * from humanresources.department where departmentid = 4;

Com essa explicação do que é um lote, agora vem a resposta para sua pergunta sobre quando encerrar os lotes. As regras para lotes são encontradas nesta referência BOL sobre lotes :

As instruções CREATE DEFAULT, CREATE FUNCTION, CREATE PROCEDURE, CREATE RULE, CREATE SCHEMA, CREATE TRIGGER e CREATE VIEW não podem ser combinadas com outras instruções em um lote. A instrução CREATE deve iniciar o lote. Todas as outras instruções que seguem nesse lote serão interpretadas como parte da definição da primeira instrução CREATE.

Uma tabela não pode ser alterada e as novas colunas referenciadas no mesmo lote.

Se uma instrução EXECUTE for a primeira instrução em um lote, a palavra-chave EXECUTE não será necessária. A palavra-chave EXECUTE é necessária se a instrução EXECUTE não for a primeira instrução do lote.

Da mesma forma, certos erros de tempo de execução (erros de compilação não permitem que a execução de um lote seja iniciado) que ocorrem durante um lote podem causar diferentes comportamentos: abortar o lote totalmente ou continuar o lote e apenas abortar a instrução incorreta (o acima link fornece dois exemplos realmente bons: um erro de estouro aritmético, por exemplo, interromperá a execução do lote, enquanto um erro de violação de restrição impedirá apenas a conclusão da instrução atual, mas o lote continuará sendo executado).

Como muitas coisas em nossa profissão, porém, a preferência pessoal será uma grande força motriz por trás de como você, como indivíduo e escritor de código T-SQL, encerra lotes. Algumas pessoas apenas definem lotes explicitamente quando absolutamente necessário (veja acima para esses requisitos), e outras encerram lotes programaticamente 100% do tempo , mesmo quando estão executando apenas uma única instrução em uma janela de consulta no SSMS. A maioria das pessoas normalmente fica em algum lugar no meio desses dois limites. Por que vale a pena, os terminadores de instrução têm os mesmos seguidores com muito poucos requisitos obrigatórios. Uma grande parte de tudo isso é o estilo de código , onde não é aplicado (em SSMS e SQLCMD).