Hogyan kombináljuk a potenciális indexek

szavazat
0

Néhány „hiányzó index” kódot (lásd alább) kaptam internetes keresések sorolja sok potenciális hiányzó indexek egy adott táblán. Szó szerint azt mondja, hogy szükségem van 30 indexek. Én már 8 futtatása előtt a kódot. A legtöbb szakértő azt állítják, hogy egy asztal kell átlagosan 5 Lehet kombinálni a legtöbb ilyen hiányzó indexek úgy, hogy lefedi a táblázatok indexel igényeit?

Például: Ez a két indexek eléggé hasonló, hogy úgy tűnik, mintha össze lehetne. De vajon?

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

Ha össze őket, hogy nézne ki, mint ez:

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

Megjegyzés: Én csak arra az első állítás és a hozzáadott [SecRestOnly]rá.

Kérdés: ezek egyesítésével kielégíti mind index igényeit? És ha nem, akkor hogyan lenne egy erősen használt asztal, sok területen már csak meg 5 indexeket?

Itt a kód használható, hogy a „hiányzó indexek”:

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;```
A kérdést 10/10/2019 00:49
a forrás felhasználó
Más nyelveken...                            


1 válasz

szavazat
1

A minta, amit adtál nem adja meg a kívánt eredményt. Az index a ([PatSample], [SecRestOnly]) optimalizálni fogja keresési feltétel, mint például "PatSample = ért1 és SecRestOnly = ért2". Az egyesített index nem, mert vannak más szegmensek között két oszlop a keresési feltételt. A legfontosabb, hogy emlékszik, hogy több szegmentált index csak akkor használható, hogy optimalizálja több „egyenlőség” keresés, ha az oszlopok a keresési a kezdeti egymást követő szegmensek az index.

Tekintettel arra, hogy meg lehet indokolni, hogy tegyük fel, hogy van egy index (col1, col2) és egy másik (col1, col2, Col3), akkor az előbbi nincs szükség.

Hány index, hogy egy kompromisszumot frissítés teljesítmény és keresési teljesítmény. Több index lelassul betét / frissítése / törlése de adok lekérdezésoptimalizáló több lehetőséget, hogy optimalizálja kereséseket. Mivel a példát, nem az alkalmazás igényel keres az „SecRestOnly” önmagában gyakran ha ez a helyzet, akkor jobb lenne, hogy van egy index „secRestOnly” önmagában vagy az első szegmens egy több részes index. Ha a keresés ritkán kerül sor az oszlopon, akkor lehet ésszerűen nincs ilyen index.

Válaszolt 10/10/2019 03:23
a forrás felhasználó

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