Escopo: Uma tabela de bilhões de registros que é indexada de 10 maneiras. A taxa de variação por dia é de 1/2 por cento.
Alguns dos índices estão aumentando monotonamente (datetime/timestamp), mas as consultas comuns provavelmente atingem o final. Presumo que as estatísticas precisem ser atualizadas com frequência para esse tipo, caso contrário, os dados recentes não serão representados no índice?
Outros índices são distribuídos de forma mais aleatória, por exemplo (chave do cliente, data e hora). Estes podem prescindir de atualizações menos frequentes, já que as estatísticas são bastante representativas do todo. Podemos deixar o índice mudar o suficiente para forçar atualizações automáticas de estatísticas neles, correto?
Para ambos os tipos, há algum benefício em aumentar a amostragem de 10% para 100%, se os dados a serem amostrados forem aleatórios e bastante representativos do todo?
Procurando as melhores práticas com dados de TB.
Se você sempre consulta a cauda, pode dar uma chance aos índices filtrados. Indexe 10 maneiras com, digamos,
WHERE datetimecolumn > @INDEXBUILDDAY-30. Periodicamente (diariamente, semanalmente?) você pode mover esse filtro para frente adicionando (online) um novo conjunto de índices filterd e, em seguida, eliminando os antigos. Com um tamanho muito menor e uma construção muito mais recente (o que implica estatísticas recentes), eles seriam 'frescos' e muito apetitosos para o otimizador. A reconstrução periódica nem precisa varrer a tabela base (sem IO enorme, sem poluição do cache de BP), o índice filtrado antigo deve sempre ser usado como uma fonte para criar o próximo índice filtrado (cobre-o).Para as consultas que ficam fora da cauda filtrada coberta, você pode manter alguns índices completos e não filtrados (menos de 10 maneiras, com sorte). Com a invocação voodoo certa, o otimizador pode entender seu ponto e usar os filtrados quando apropriado e apenas recorrer aos completos quando necessário...
Existem alguns sinalizadores de rastreamento que podem ajudar com estatísticas sobre chaves ascendentes, TF2389 e TF2390.
Desde 2005SP1, o SQL Server identificou e "marca" as chaves ascendentes. Se TF2389 for definido e a coluna inicial de um índice de cobertura for marcada, as estatísticas da coluna serão atualizadas automaticamente identificando o valor de chave mais alto e atualizando o histograma existente. Habilitar TF2930 faz com que a mesma atualização ocorra onde uma coluna não foi identificada (marcada) como ascendente.
Lembre-se de que a atualização das estatísticas ocorre durante a compilação da consulta, portanto, se a recompilação for rara, convém testar uma dica RECOMPILE em alguns procedimentos ou consultas para forçar uma atualização. Como alternativa, um sp_recompile periódico no procedimento pode ajudar se o custo da compilação for alto.
Estatísticas sobre colunas ascendentes é um ótimo artigo que cobre a mecânica.
NB: As advertências usuais ao uso de sinalizadores de rastreamento se aplicam ... teste, teste e teste mais um pouco.