Maus hábitos:contar as linhas da maneira mais difícil

Quantas linhas na tabela?

SELECT @count = COUNT(*) FROM dbo.tablename;

SELECT @count = SUM(p.rows)
  FROM sys.partitions AS p
  INNER JOIN sys.tables AS t
  ON p.[object_id] = t.[object_id]
  INNER JOIN sys.schemas AS s
  ON t.[schema_id] = s.[schema_id]
  WHERE p.index_id IN (0,1) -- heap or clustered index
  AND t.name = N'tablename'
  AND s.name = N'dbo';

"Mas não posso usar os DMVs; minha contagem precisa ser super precisa!"

Uma contagem "super precisa" na verdade não tem sentido. Vamos considerar que sua única opção para uma contagem "super precisa" é bloquear a tabela inteira e proibir qualquer pessoa de adicionar ou excluir qualquer linha (mas sem impedir leituras compartilhadas), por exemplo:


SELECT @count = COUNT(*) FROM dbo.table_name WITH (TABLOCK); -- not TABLOCKX!


Então, sua consulta está zunindo, varrendo todos os dados, trabalhando em direção a essa contagem "perfeita". Enquanto isso, as solicitações de gravação estão sendo bloqueadas e aguardando. De repente, quando sua contagem precisa é retornada, seus bloqueios na mesa são liberados e todas as solicitações de gravação que estavam enfileiradas e aguardando, começam a disparar todos os tipos de inserções, atualizações e exclusões em sua tabela. Quão "super precisa" é a sua contagem agora? Valeu a pena obter uma contagem "precisa" que já é terrivelmente obsoleta? Se o sistema não estiver ocupado, então isso não é um problema tão grande - mas se o sistema não estiver ocupado, eu argumentaria fortemente que os DMVs serão bastante precisos.

Você poderia ter usado NOLOCK em vez disso, mas isso significa apenas que os escritores podem alterar os dados enquanto você os lê e leva a outros problemas também (falei sobre isso recentemente). Tudo bem para muitos estádios, mas não se seu objetivo for precisão. Os DMVs estarão bem (ou pelo menos muito mais próximos) em muitos cenários e mais distantes em muito poucos (na verdade, nenhum que eu possa pensar).

Por fim, você pode usar o isolamento de instantâneos confirmados de leitura. Kendra Little tem um post fantástico sobre os níveis de isolamento de snapshots, mas vou repetir a lista de advertências que mencionei no meu NOLOCK artigo:

• Os bloqueios Sch-S ainda precisam ser feitos mesmo sob RCSI.
• Os níveis de isolamento de instantâneo usam controle de versão de linha no tempdb, então você realmente precisa testar o impacto lá.
• RCSI não pode usar varreduras de ordem de alocação eficientes; você verá varreduras de intervalo.
• Paul White (@SQL_Kiwi) tem ótimas postagens que você deve ler sobre esses níveis de isolamento:
  • Ler o isolamento de instantâneo confirmado
  • Modificações de dados no isolamento de instantâneos confirmados de leitura
  • O nível de isolamento do INSTANTÂNEO

Além disso, mesmo com RCSI, obter a contagem "precisa" leva tempo (e recursos adicionais no tempdb). No momento em que a operação é concluída, a contagem ainda é precisa? Só se ninguém tiver tocado na mesa nesse meio tempo. Portanto, um dos benefícios do RCSI (os leitores não bloqueiam os escritores) é desperdiçado.

Quantas linhas correspondem a uma cláusula WHERE?

• Índice filtrado – por exemplo, se você tiver um filtro simples como is_active = 1 ou status < 5 , então você poderia construir um índice como este:

  CREATE INDEX ix_f ON dbo.table_name(leading_pk_column) WHERE is_active = 1;

  
  Agora, você pode obter contagens bastante precisas dos DMVs, pois haverá entradas representando esse índice (você só precisa identificar o index_id em vez de confiar no heap(0)/índice clusterizado(1)). No entanto, você precisa considerar alguns dos pontos fracos dos índices filtrados.
• Visualização indexada - por exemplo, se você costuma contar pedidos por cliente, uma visualização indexada pode ajudar (embora não tome isso como um endosso genérico de que "visualizações indexadas melhoram todas as consultas!"):
  

  CREATE VIEW dbo.view_name
  WITH SCHEMABINDING
  AS
    SELECT 
      customer_id, 
      customer_count = COUNT_BIG(*)
    FROM dbo.table_name
    GROUP BY customer_id;
  GO
   
  CREATE UNIQUE CLUSTERED INDEX ix_v ON dbo.view_name(customer_id);

  
  Agora, os dados na visão serão materializados, e a contagem é garantida para ser sincronizada com os dados da tabela (há alguns bugs obscuros onde isso não é verdade, como este com MERGE , mas geralmente isso é confiável). Portanto, agora você pode obter suas contagens por cliente (ou para um conjunto de clientes) consultando a visualização, a um custo de consulta muito menor (1 ou 2 leituras):
  

  SELECT customer_count FROM dbo.view_name WHERE customer_id = <x>;

  
  Mas não existe almoço grátis . Você precisa considerar a sobrecarga de manter uma exibição indexada e o impacto que isso terá na parte de gravação de sua carga de trabalho. Se você não executar esse tipo de consulta com muita frequência, é improvável que valha a pena.

Pelo menos uma linha corresponde a uma cláusula WHERE?

IF (SELECT COUNT(*) FROM dbo.table_name WHERE <some clause>) > 0 -- or = 0 for not exists

IF EXISTS (SELECT 1 FROM dbo.table_name WHERE <some clause>)