Estou apenas pensando em criar NONCLUSTERED FILTERED INDEXcom condição:
WHERE varcharColumn <> ''
Esta coluna contém cerca de 3127 valores diferentes, incluindo value ''. Todas as consultas têm condição que estão sendo executadas nesta tabela têm condição:
WHERE varcharColumn <> ''
90% das linhas contêm a string vazia e seriam excluídas por esse filtro.
Você acha que vale a pena criar esse índice com a cláusula acima? Ou talvez seja melhor criar NONCLUSTERED FILTERED INDEXcom cláusula:
WHERE varcharColumn = ''
Se suas consultas contiverem principalmente a
WHERE varcharColumn <> ''condição, então é aquela que você precisa usar para o índice - um índice filtrado contém apenas referências às linhas que correspondem à condição, portanto, usar=na definição do índice significaria que apenas as linhas com''podem ser encontradas e ganhou não ajudar suas perguntas.Se
varcharColumn <> ''for apenas ~ 10% da tabela, o índice será bem pequeno, rápido e muito útil também. Se a proporção fosse invertida, o índice provavelmente não ajudaria muito e levaria apenas (mais) espaço.Isso excluiria apenas 10% dos dados, ponto em que você certamente estará melhor com um índice não filtrado que também pode ser usado para consultar outros valores.
Em 90%, o índice filtrado não é muito útil, mesmo para consultas em que
varcharColumn = ''é um predicado, pois você estará verificando quase todo o índice de qualquer maneira (a menos que algum outro índice atenda melhor à consulta, caso em que esse índice não é relevante).Observe que, na maioria dos casos, isso não melhorará significativamente as velocidades de leitura em comparação com um índice completo¹. No entanto, isso pode economizar uma quantidade notável de espaço² se a tabela contiver um número significativo de linhas, o que pode reduzir o custo de armazenamento e os tempos de manutenção do índice e pode melhorar um pouco o desempenho de inserção/atualização para linhas em que esse valor é a string vazia.
[1] ele cortará uma ou duas páginas lidas de qualquer ação, e essas leituras provavelmente seriam da RAM tão quase instantânea
[2] aproximadamente 90% de 4 bytes por linha na tabela assumindo MS SQL Server e a chave de cluster³ é um número inteiro, 16 bytes por linha se a chave de cluster for um UUID, 8 bytes, o tamanho de um valor RID, por linha se a tabela for uma cabeça (sem chave de clustering)
[3] geralmente, mas nem sempre, a chave primária