Considere o seguinte cenário:
- 10.000 usuários tentam criar um perfil em nosso aplicativo simultaneamente ao mesmo tempo e os dados devem ser inseridos na tabela, userProfile.
- O SP que lida com essa inserção leva meio segundo para ser executado.
Do meu entendimento de bloqueio e transações, esta tabela será bloqueada para cada inserção. Isso significa que, quando o perfil do último usuário for criado, levará um tempo. Como o SQL Server lida com atualizações e bloqueios simultâneos? Eu apreciaria qualquer insight sobre isso. Obrigado!
Esta é uma área bastante ampla e livros inteiros foram escritos sobre o assunto, e muitos artigos curtos e longos foram escritos sobre detalhes específicos, portanto, responderei apenas aos seus pontos específicos e, com sorte, fornecerei algumas palavras-chave para pesquisar para leitura adicional.
Isso não é verdade. Os bloqueios podem ser tão pequenos quanto uma página ou uma única linha, não necessariamente a tabela inteira; portanto, a atividade simultânea de leitura de outras páginas ainda pode continuar simultaneamente - portanto, o aplicativo provavelmente pode ler sua linha de perfil, permitindo que você faça login ou outros para visualize sua biografia, enquanto os perfis de outras pessoas estão sendo criados.
Diferentes opções de transação e bloqueio podem ajudar na simultaneidade de muitas inserções, por exemplo, o isolamento de instantâneo permitirá leituras que podem ser bloqueadas aguardando a adição de novas linhas (como consultas que leem a tabela inteira, embora sejam raras) para serem concluídas, mas apenas vendo o estado confirmado do banco de dados quando a transação foi iniciada.
Há um problema específico com o incremento de índices inteiros, geralmente usados como chaves primárias para tais tabelas, que podem causar contenção criando muitas novas linhas: procure “contenção da última página” para obter mais informações. O SQL Server 2019 e superior possui uma otimização de índice específica para isso, OPTIMIZE_FOR_SEQUENTIAL_KEY. Porém, se você está no nível de se preocupar com bloqueios de tabelas inteiras, está longe de precisar saber detalhes íntimos aqui.
Esse problema não deve afetar outras consultas simultâneas: como as leituras acima que não precisam se preocupar com a última página dos índices, não devem ser bloqueadas aguardando a conclusão dessa atividade, a menos que você tenha realmente sobrecarregado os recursos disponíveis do servidor.
Além disso, o restante da infraestrutura do seu aplicativo suportará realisticamente 10 mil solicitações simultâneas para transmitir essa carga no SQL Server?! O seu servidor web (assumindo esse tipo de aplicativo) pode aceitar e processar tantas conexões simultâneas, etc.
Se você está apenas criando uma única linha para o novo perfil, meio segundo é duas ou três ordens de magnitude muito alto, a menos que você esteja executando em um hardware realmente muito antigo/ estranho ou usando um provedor VPS estupendamente supervendido. Deve ser mais como um par de centésimos de segundo ou menos.
Se estiver fazendo alguma outra lógica mais complexa junto com a criação dessa linha, um design cuidadoso deve permitir que você minimize o período de tempo que mantém os bloqueios na tabela de perfil do usuário. Se a lógica desse procedimento for tão complexa, você precisa se preocupar mais com o design para reduzir os impasses do que com a simultaneidade massiva, então talvez simplifique esse procedimento. É claro que você poderia tentar resolver um problema de impasse ingênuo definindo todos os níveis de isolamento de sua transação como serializáveis, mas então você está criando o mesmo problema com o qual começou a se preocupar (fazendo com que cada instrução tocando nessa tabela espere que as outras sejam concluídas).
Os documentos do Microsoft Learn sobre bloqueio de transação e guia de versão de linha podem ser um bom lugar para começar a leitura geral. Se isso for um pouco profundo para você inicialmente, tente pesquisar palavras-chave relevantes para encontrar descrições mais projetadas para tutoriais e retorne ao material de referência mais seco quando tiver um pouco mais de base sobre o básico e, é claro, retorne aqui quando tiver perguntas mais específicas .