Tips på hur du optimerar icke-Clustrade SQL Server Index
Förord
Innehåll
Tips på hur du optimerar icke-Clustrade SQL Server Index
Icke-Clustrade Index fungerar bäst på SQL-satser:
- Som returnerar få poster (inkluderat även en enda post) och där Indexet har en god selektivitet (mer än 95 %).
- Som returnerar små mängder data (inte stora mängder). För stora mängder data krävs Clustrade Index för bättre prestation.
- Där både WHERE och ORDER BY klausulen i en SQL-sats är specificerade för samma kolumn. På så sätt gör det icke-Clustrade Indexet två saker i taget. Det hjälper till att snabba på accessen för recorden, och det snabbar också på sorteringen av de data som hämtas ut (eftersom det redan är sorterat när det hämtas ut).
- Som använder JOINs (trots att Clustrade Index är bättre för det).
[SQL Server 6.5, 7.0, 2000] Uppdaterad 02-02-08.
*****
Om en kolumn i en tabell inte är åtminstone 95 % unikt så är det högst troligt att Query Optimizern inte kommer att använda ett icke-Clustrat Index baserat på den kolumnen. På grund av det så bör du inte skapa ett icke-Clustrat Index på kolumner som inte är åtminstone 95 % unika. En kolumn med data som t ex ”Ja” eller ”Nej” kommer inte att vara misnt 95 % unikt. [SQL Server 6.5, 7.0, 2000]
*****
Om din tabell behöver något icke-Clustrat Index så bör du försäkra dig om att det Indexet läggs till innan du skapar något icke-Clustrat Index. Om du inte gör det, och lägger till ett Clustrat Index, så måste alla icke-Clustrade Index som fanns där innan återskapas (vilket görs automatiskt medan det Clustrade Indexet skapas), vilket också skapar extra arbete åt din Server. [SQL Server 6.5, 7.0, 2000] Inlagd 00-10-05.
*****
För att avgöra selektiviteten på ett Index i en given tabell så kan du köra kommandot:
DBCC SHOW_STATISTICS (table_name, index_name)
Ju högre selektivitet ett Index har, desto troligare är det att Indexet kommer att användas av Query Optimizer. [SQL Server 6.5, 7.0, 2000]
*****
Trots att en kolumn (eller kolumner om det är ett kombinerat Index) har ett icke-Clustrat Index, så kan det i vissa fall ske så att Query Optimizer inte använder det (även om den borde det). Den kan istället göra en tabellscan (om tabellen är en stor samling) eller en scan av ett Clustrat Index (om det finns något Clustrat Index). Det här kan självklart skapa vissa prestandaproblem som man inte vill ha.
Just det här problemet kan uppstå då det finns data kopplingen mellan sorteringen av posterna i en tabell, samt sorteringen mellan de lagrade icke-Clustrade Indexen. Det här kan uppstå då det finns en koppling mellan de Clustrade Indexen och de icke-Clustrade Indexen. Det Clustrat Indexet kan t ex skapas på datumkolumnen, medan det skapas ett icke-Clustrat Index på en sifferkolumn. Om så är fallet så skapas det en koppling (eller en direkt relation) mellan de ökande datumen och de ökande siffrorna som går att finna i varje post.
Anledningen till att det här problemet uppstår är därför att Query Optimizer antar att det inte finns någon koppling, och den gör dess val baserat på dessa antaganden.
Om du skulle stöta på detta problem så finns de tre olika lösningar:
- Om det är möjligt så bör du sortera om kolumnerna i det icke-Clustrade Indexet (förutsatt att det är ett kombinerat Index), så att kolumnen av högsta betydelse är den första kolumnen i det täckande Indexet.
- Skapa täckande Index.
- Lägg till Indexlösningar till dina SQL-satser som jobbar över Query Optimizer.
[SQL Server 7.0, 2000] Inlagd 01-06-28.
0 Kommentarer