Hvordan kombinere potensielle indekser

stemmer
0

Noen mangler indeks kode (se nedenfor) Jeg fikk fra Internett-søk blir notering mange potensielle mangler indekser for en bestemt tabell. Bokstavelig talt er det å si at jeg trenger 30 indekser. Jeg hadde allerede åtte før du kjører koden. De fleste eksperter sier at en tabell bør gjennomsnittlig 5. Kan jeg kombinere et flertall av disse manglende indekser slik at den dekker de fleste av bordene indeksering behov?

For eksempel: Disse to indeksene er like nok til at det virker som de kan kombineres. Men kan de?

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

Hvis jeg kombinere dem det ville se slik ut:

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

MERK: Jeg bare tok den første setningen og lagt [SecRestOnly]til det.

SPØRSMÅL: Vil kombinere disse tilfredsstiller begge peke behov? Og hvis ikke, hvordan ville en meget brukt bord med mange felt noen gang bare har 5 indekser?

Her er koden som brukes for å få manglende indekser:

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;```
Publisert på 09/10/2019 klokken 23:49
kilden bruker
På andre språk...                            


1 svar

stemmer
1

Prøven du ga ikke vil gi deg ønsket resultat. Indeksen på ([PatSample], [SecRestOnly]) vil optimalisere søk tilstand som for eksempel "PatSample = VAL1 og SecRestOnly = VAL2". Den kombinerte indeks vil ikke fordi det er andre segmenter mellom de to kolonnene i søkebetingelsen. Nøkkelen til husker er at multisegmenterte indeks kan bare brukes til å optimalisere søk flere "likhet" når kolonnene i søket er de første segmenter etter hverandre i indeksen.

Gitt at det kan være begrunnet at anta at du har en indeks på (col1, col2) og en annen på (col1, col2, kol3), da det tidligere ikke er nødvendig.

Hvor mange indeksen å ha er en avveining mellom oppdatering ytelse og søke ytelse. Mer indeksen vil avta innsats / oppdatere / slette, men vil gi spørringsoptimisereren flere alternativer for å optimalisere søk. Gitt ditt eksempel, gjør din søknad krever å søke på "SecRestOnly" av seg selv ofte, hvis det er tilfelle, ville det være bedre å ha en indeks med "secRestOnly" alene eller som den første delen av et multi-segment-indeksen. Hvis søket blir sjelden gjort på kolonnen, så kan det være fornuftig å ikke ha en slik indeks.

Svarte 10/10/2019 kl. 02:23
kilden bruker

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