Jak połączyć potencjalnych indeksów

głosy
0

Niektóre „missing index” kod (patrz poniżej) Mam od poszukiwania w internecie wystawiasz wiele potencjalnych brakujących indeksów dla danej tabeli. Dosłownie to mówiąc, że muszę 30 indeksów. Miałem już 8 przed uruchomieniem kodu. Większość ekspertów stwierdza, że ​​tabela powinna średnio 5. Czy mogę połączyć większość tych brakujących indeksów tak, że obejmuje większość tabeli indeksujących potrzeb?

Na przykład Oba wskaźniki są na tyle podobne, że wydaje się, że mogą być łączone. Ale oni mogą?

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])

Gdybym je połączyć to by wyglądać tak:

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

UWAGA: Właśnie zajął pierwsze oświadczenie i dodaje [SecRestOnly]do niego.

PYTANIE: Czy łącząc je zaspokoić zarówno potrzeby indeksu? A jeśli nie, w jaki sposób wysoce używany stół z dużą ilością pól kiedykolwiek tylko mają 5 indeksów?

Oto kod używany do dostać „brakujące indeksy”:

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;```
Utwórz 10/10/2019 o 00:49
źródło użytkownik
W innych językach...                            


1 odpowiedzi

głosy
1

Próbka dałeś nie daje pożądanego rezultatu. Wskaźnik na ([PatSample] [SecRestOnly]) będzie optymalizować stan wyszukiwania, takich jak "PatSample = wart1 i SecRestOnly = wart2". Połączone indeks nie będzie, ponieważ istnieją inne segmenty pomiędzy dwoma kolumnami w stanie wyszukiwania. Kluczem jest to, że pamięta multi-segmentowy wskaźnik może być stosowany jedynie w celu optymalizacji wielu „równości” szukanie gdy kolumny w poszukiwaniu to początkowe kolejne segmenty wskaźnika.

Biorąc pod uwagę, że może on być uzasadniony przypuszczać, że masz jeden indeks na (col1, col2), a inny na (col1, col2, Col3), to pierwsze nie jest potrzebne.

Ile Indeks mieć to kompromis pomiędzy wydajnością aktualizacji i wyników wyszukiwania. Więcej indeks spowolni insert / update / delete, ale da optymalizator kwerendy więcej opcji w celu optymalizacji wyszukiwania. Biorąc pod uwagę Twój przykład, czy aplikacja wymaga poszukiwania na „SecRestOnly” sam często, jeśli tak jest, to byłoby lepiej mieć indeks z „secRestOnly” sam lub jako pierwszego segmentu indeksu wielosegmentowego. Jeżeli wyszukiwanie jest rzadko odbywa się w kolumnie, to może to być rozsądne, aby nie mieć takiego indeksu.

Odpowiedział 10/10/2019 o 03:23
źródło użytkownik

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