Como combinar potenciais índices

votos
0

Algum código índice faltando (veja abaixo) que eu tenho de buscas na internet está listando uma série de potenciais índices em falta para uma determinada tabela. Literalmente ele está dizendo que eu preciso de 30 índices. Eu já tinha 8 antes de executar o código. A maioria dos especialistas afirmam que uma tabela deve média de 5. Posso combinar a maioria desses índices faltantes para que ele cobre a maioria das tabelas de indexação necessidades?

Por exemplo: Estes dois índices são suficientemente semelhantes que parece que elas podem ser combinadas. Mas eles podem?

CREATE INDEX [NCI_12345] ON [DB].[dbo].[someTable] ([PatSample], [StatusID], [Sub1Sample]) INCLUDE ([PatID], [ProgID], [CQINumber])


CREATE INDEX [NCI_2535_2534] ON [DB].[dbo].[someTable] ([PatSample], [SecRestOnly]) INCLUDE ([CQINumber])

Se eu combiná-los ele ficaria assim:

CREATE INDEX [NCI_12345] ON [DB].[dbo].[someTable] ([PatSample], [StatusID], [Sub1Sample], [SecRestOnly]) INCLUDE ([PatID], [ProgID], [CQINumber])

NOTA: Eu apenas tomei a primeira declaração e acrescentou [SecRestOnly]a ele.

PERGUNTA: Será que a combinação destes satisfazer ambas as necessidades de índice? E se não, como seria uma mesa muito utilizado com lotes de campos já só tem 5 índices?

Aqui está o código utilizado para obter índices ausentes:

SELECT
   migs.avg_total_user_cost * (migs.avg_user_impact / 100.0) * (migs.user_seeks + migs.user_scans) AS improvement_measure, LEFT (PARSENAME(mid.STATEMENT, 1), 32) as TableName,
  'CREATE INDEX [NCI_' + CONVERT (VARCHAR, mig.index_group_handle) + '_' + CONVERT (VARCHAR, mid.index_handle)
  + '_' + LEFT (PARSENAME(mid.STATEMENT, 1), 32) + ']'
  + ' ON ' + mid.STATEMENT
  + ' (' + ISNULL (mid.equality_columns,'')
    + CASE WHEN mid.equality_columns IS NOT NULL AND mid.inequality_columns IS NOT NULL THEN ',' ELSE '' END
    + ISNULL (mid.inequality_columns, '')
  + ')'
  + ISNULL (' INCLUDE (' + mid.included_columns + ')', '') AS create_index_statement,
  migs.*, mid.database_id, mid.[object_id]
FROM [sys].dm_db_missing_index_groups mig
INNER JOIN [sys].dm_db_missing_index_group_stats migs ON migs.group_handle = mig.index_group_handle
INNER JOIN [sys].dm_db_missing_index_details mid ON mig.index_handle = mid.index_handle
WHERE migs.avg_total_user_cost * (migs.avg_user_impact / 100.0) * (migs.user_seeks + migs.user_scans) > 10
ORDER BY migs.avg_total_user_cost * migs.avg_user_impact * (migs.user_seeks + migs.user_scans) DESC;```
Publicado 10/10/2019 em 00:49
fonte usuário
Em outras línguas...                            


1 respostas

votos
1

O exemplo que você deu não vai lhe dar o resultado desejado. O índice de ([PatSample], [SecRestOnly]) vai optimizar a condição de pesquisa, tais como "PatSample = val1 e SecRestOnly = val2". O índice combinado não será porque existem outros segmentos entre as duas colunas na condio de pesquisa. A chave para se lembra é que o índice de multi-segmentado só pode ser utilizado para optimizar a pesquisa múltipla "igualdade", quando as colunas na pesquisa são as iniciais segmentos consecutivos do índice.

Dado que, pode ser fundamentado que suponha que você tenha um índice em (col1, col2) e outra em (col1, col2, col3), então o primeiro não é necessário.

Quantas índice é ter um trade-off entre o desempenho de atualização e desempenho da pesquisa. Mais índice vai abrandar insert / update / delete mas vai dar otimizador de consulta mais opções para otimizar pesquisas. Dado o seu exemplo, que a sua aplicação requer pesquisando na "SecRestOnly" por si só muitas vezes, se for esse o caso, seria melhor ter um índice com "secRestOnly" por si só ou como o primeiro segmento de um índice multi-segmento. Se a pesquisa é raramente feito na coluna, então ele pode ser razoável para não ter tal índice.

Respondeu 10/10/2019 em 03:23
fonte usuário

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more