O que é e como funciona na prática
A atividade de sequência em SQL Server é basicamente um contador gerado automaticamente pelo banco, útil quando você precisa de IDs numéricos exclusivos sem depender de campos identity. Diferente do auto-incremento tradicional, a sequência é um objeto separado que pode ser compartilhado entre várias tabelas. O comando padrão é CREATE SEQUENCE com opções de INCREMENTO, MINVALUE e MAXVALUE. Na prática, a forma mais comum de consumir os valores é usando NEXT VALUE FOR dentro de um INSERT, ou atribuindo a variáveis com SELECT.
Como montar sua primeira atividade de sequencia
Comece criando a sequência diretamente no banco. O script básico leva menos de 10 linhas e você já pode testar no SSMS sem complicação: CREATE SEQUENCE dbo.SeqPedidos
AS INT
START WITH 1
INCREMENT BY 1
NO MINVALUE
NO MAXVALUE
NO CYCLE;
Depois disso, o uso é direto. Um INSERT simples com NEXT VALUE FOR resolve a maioria dos casos no dia a dia. Se precisar puxar o próximo valor antes do insert, uma variável do tipo INT recebe o resultado da função e você insere manualmente. Funciona bem para cenários onde o ID precisa ser conhecido antes da operação principal, como em transações que envolvem múltiplas tabelas relacionadas. O problema real começa quando você trabalha com ambientes de desenvolvimento que são constantemente restaurados a partir do produção. Eu lidei com isso há cerca de dois anos num projeto de migração onde a sequência estava no milhão e a tabela só tinha cem registros. O insert falhava silenciosamente porque o valor da sequência já ultrapassava o MAXVALUE configurado. A solução foi um script de reset rodando antes de cada restore, comparando o CURRENT_VALUE da sequência com o MAX_ID da tabela e ajustando conforme necessário. Isso economizou umas duas horas por semana que eu perdia corrigindo inserts frustrados.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Detalhes que passam despercebidos
A maioria das pessoas não percebe que a sequência não é transacional. Se você chamar NEXT VALUE FOR dentro de uma transação que é rollada depois, o valor consumido não volta. Isso significa que gaps na numeração são esperados, não bugs. Em cenários onde a continuidade numérica é requisito do negócio, sequência não é a ferramenta certa. Use identidade com seed fixo ou gere os números em aplicação. Outro ponto que causa dor de cabeça é o cache. Por padrão, o SQL Server armazena em cache 50 valores da sequência. Se o servidor cair, todos os valores em cache são perdidos e o próximo número vem com um salto. Configurar WITH NO CACHE elimina o cache mas impacta performance em cargas altas. Em sistemas com milhares de inserts por segundo, o overhead pode ser relevante. O equilíbrio depende do volume. Para rotinas administrativas e relatórios internos, o cache padrão não causa problemas perceptíveis.
Também vale saber que sequences suportam múltiplos schemas e você pode especificar schema.sequencename ao referenciar. Isso ajuda quando o mesmo nome de sequência é usado em bases diferentes dentro do mesmo ambiente, algo comum em projetos multi-tenant.
Erros comuns ao implementar
O erro mais frequente é configurar MAXVALUE pequeno achando que vai proteger contra valores altos. Na prática, isso gera erros de overflow difíceis de rastrear porque a mensagem de erro não menciona a sequência explicitamente. Sempre deixe NO MAXVALUE ou use um valor bem acima do esperado. Outro problema é confundir o comportamento de ALTER SEQUENCE com RESTART. Mudar o START VALUE via ALTER não reseta a sequência automaticamente. Você precisa usar RESTART WITH junto ou chamarNEXT VALUE FOR depois do alter para ver o novo valor. Sem isso, a sequência continua do ponto onde estava e o alter parece não ter feito nada.
Para quem está começando, o caminho mais seguro é criar a sequência, testar com inserts controlados em banco de desenvolvimento e verificar o CURRENT_VALUE após cada operação. Uma view simples com SELECT seq.name, seq.current_value, seq.min_value, seq.max_value de sys.sequences resolve a maior parte das dúvidas sobre o estado atual. Se o seu cenário exige garantias de não repetição em transações abortadas ou se você precisa de numeração contínua sem gaps, considere manter a lógica de geração no application layer ou usar table hints com serializable para controle mais rigoroso. Sequência é prática para a maioria dos casos, mas não é universal.