Início / dba / Perguntas / 21739
Accepted
user529265
Asked: 2012-08-01 00:27:30 +0800 CST

seleção única vs seleções múltiplas usando limite e deslocamento

  • 772

Trabalhando em um site de volume razoavelmente alto. Existem alguns exemplos de tabelas - a tabela de clientes que é muito atingida.

O problema

Estamos escrevendo um trecho de código que seleciona um grupo de clientes e envia malas diretas, etc. (nada de missão crítica). Essas seleções geralmente resultam em cerca de 20.000 registros. Obviamente, não queremos que os acessos regulares à tabela do cliente sejam bloqueados por essas instruções select.

Seguimos o caminho de fazer essas leituras readUncommitted, pois as operações nos dados não são absolutamente críticas para a missão.

No entanto, em vez de fazer essas seleções massivas, se no código fizermos uma seleção com um limite e um deslocamento e continuarmos em loop, isso causaria menos bloqueios no banco de dados.

Em outras palavras - 20 instruções select, cada uma recuperando 1.000 registros, seriam mais desejáveis ​​do que 1 instrução select recuperando 20.000 registros em termos de redução de bloqueio, etc.

Qualquer sugestão seria muito apreciada.

sql-server-2008 azure-sql-database

3 respostas

  1. Ok, primeira coisa, preciso escolher um pouco sobre isso:

    Seguimos o caminho de fazer essas leituras readUncommitted, pois as operações nos dados não são absolutamente críticas para a missão.

    O uso READ UNCOMMITTEDde / NOLOCKsó deve ser considerado quando a precisão dos resultados não for crítica, pois é isso que afeta o nível de isolamento da transação. Entendo que a operação não é de missão crítica , mas esse não deve ser o motivo por trás da seleção de um nível de isolamento menos restritivo.

    Em outras palavras - 20 instruções select, cada uma recuperando 1.000 registros, seriam mais desejáveis ​​do que 1 instrução select recuperando 20.000 registros em termos de redução de bloqueio, etc.

    Se você continuar a usar READ UNCOMMITTED, a sobrecarga de bloqueio será a mesma entre os dois métodos (ou seja, nenhum bloqueio será obtido). No entanto, a execução de várias instruções em vez de uma pode afetar outras coisas, como a compilação de consultas (que usa CPU), a tagarelice da rede e a complexidade de seu aplicativo. Nesse caso, acho que a operação de envio de mala direta seria relativamente pouco frequente (posso estar errado), portanto, o último fator pode ser o mais importante a ser considerado.

    Se você optar por voltar para um nível de isolamento mais alto por motivos de precisão, esse é um jogo totalmente diferente em termos de bloqueio.

    • 3
  2. Best Answer

    20k registros não é muito. Você tem SELECTingoutros dados de outras tabelas como parte de sua correspondência, o que está atrasando as coisas? Você está mantendo sua transação aberta por mais tempo do que o necessário?

    Caso contrário, você pode usar um dos níveis de isolamento de simultaneidade opimísticos : Snapshotou Read Committed Snapshot? Eles devem permitir que você leia sem bloquear.

    • 2

  3. Você deve procurar uma indexação adequada de registros, pois os registros do SQL Server 20000 não são muito mais, você pode escolher facilmente em uma única instrução de seleção. Se possível em uma única declaração, por que deveria ir para várias.

    Portanto, a melhor solução é que, se os registros não forem recuperados rapidamente, crie os índices de acordo com a necessidade de otimizar sua instrução de seleção.

    • 1

relate perguntas