Kiedy używać indeksu złożonego i wskaźnika pokrycia w programie SQL Server?

Question

Mam 2 tabele tb_player1 i tb_player2.

CREATE TABLE tb_player1 
(
    pk_id INT PRIMARY KEY IDENTITY (1,1) NOT NULL, 
    first_name CHAR(16), 
    last_name CHAR(16), 
    age INT 
) 

CREATE NONCLUSTERED INDEX ix_nonclustered_name ON tb_player1(first_name, last_name) 

CREATE TABLE tb_player2 
(
    pk_id INT PRIMARY KEY IDENTITY (1,1) NOT NULL, 
    first_name CHAR(16), 
    last_name CHAR(16), 
    age INT 
) 

CREATE NONCLUSTERED INDEX ix_nonclustered_name ON tb_player2(first_name) 
INCLUDE (last_name) 

tb_player1 ma wskaźnik kompozytowego i tb_player2 obejmował kolumnowej (obejmujące wskaźnik).

uruchomić następujące SQL przeciwko tb_player1 i tb_player2, ale rzeczywiste wykonanie planu tb_player1 i tb_player2 są takie same.

INSERT INTO tb_player1 VALUES('kenny', 'lee', 29) 
INSERT INTO tb_player1 VALUES('rose', 'chao', 27) 
INSERT INTO tb_player1 VALUES('mark', 'chao', 25) 

INSERT INTO tb_player2 VALUES('kenny', 'lee', 29) 
INSERT INTO tb_player2 VALUES('rose', 'chao', 27) 
INSERT INTO tb_player2 VALUES('mark', 'chao', 25) 



select first_name, last_name from tb_player1 where first_name = 'kenny' 
select first_name, last_name from tb_player2 where first_name = 'kenny' 

select first_name, last_name from tb_player1 where last_name = 'lee' 
select first_name, last_name from tb_player2 where last_name = 'lee' 

select first_name, last_name from tb_player1 where first_name = 'kenny' AND last_name = 'lee' 
select first_name, last_name from tb_player2 where first_name = 'kenny' AND last_name = 'lee' 

select first_name, last_name from tb_player2 where last_name = 'lee' AND first_name = 'kenny' 
select first_name, last_name from tb_player1 where last_name = 'lee' AND first_name = 'kenny' 

Kiedy używać indeksu złożonego i wskaźnika pokrycia w programie SQL Server? Jakie są różnice między nimi? Dlaczego plan wykonania nie wygląda inaczej.

Answer 1

1. Indeks złożony (gdzie wszystkie kolumny są kolumnami "kluczowymi") będzie zawierał dane na wszystkich poziomach indeksu; indeks INCLUDE będzie nosił tylko kolumny "bez klucza" w węźle liści. Odbiór: Indeks INCLUDE będzie mniejszy niż równoważny indeks złożony.

2. Kolumny INCLUDE (bez klucza) nie będą się liczyły do ​​maksymalnego rozmiaru indeksu (900 bajtów).

3. Aktualizacje dla kolumn innych niż kluczowe w indeksach INCLUDE nie przyczynią się do fragmentacji indeksu; aktualizacje nieużywanych kolumn "klucza" w indeksie złożonym spowodują fragmentację ... IMO, to jest biggie.

4. Przy założeniu fragmentacji o niskim indeksie zarówno indeksy złożone, jak i INCLUDE będą działać w sposób porównywalny. Wszystkie kolumny w indeksie złożonym nie muszą znajdować się w predykacie zapytania.