SQL SERVER – cheie primară și index non-clustered

Când este vorba despre cheia primară și indexul grupat, iată ideea greșită comună
care predomină în industrie.

Cheia primară trebuie să fie Clustered Index. 

În realitate, afirmația ar trebui corectată după cum urmează:

Cheia primară poate fi Clustered sau Non-clustered, dar este o practică obișnuită să
creați o cheie primară ca index cluster. 

Ei bine, acum am corectat afirmația, să înțelegem puțin mai în detaliu. Cheia primară ar

trebui să fie coloana de identificare unică a tabelului și nu ar trebui să fie NULL. Un candidat
bun (de cele mai multe ori) al cheii de index grupat identifică, de asemenea, în mod unic
coloana și NOT NULL (de cele mai multe ori). Ei bine, asta înseamnă că este o idee bună
să creați o cheie primară în cluster, astfel încât să rezolve ambele probleme
împreună. Ținând cont de aceste fapte, SQL Server creează automat un index cluster pe
cheia primară atunci când tabelul este creat. De multe ori, dezvoltatorii nu specifică ce
coloană ar trebui să aibă index grupat, așa că cheia primară implicită devine Index
cluster. Această practică este acum extrem de comună și mulți oameni au uitat că Primary
Key și Clustered Index sunt două lucruri diferite. Pot fi aceeași coloană, dar nu trebuie să
fie.

Ei bine, iată patru exemple pe care le vom vedea unde vom învăța comportamentul SQL Server
atunci când este vorba despre Cheia Primară și Indexul Clustered.

 Scenariul 1: Cheia primară va fi implicit la Index cluster

 Scenariul 2: Cheia primară este definită ca un index necluster
 Scenariul 3: Cheia primară este implicită la Index non-clustered cu o altă coloană
definită ca un index cluster
 Scenariul 4: Cheia primară este implicită la Index cluster, iar alt index este implicit la
Index neclustrat

Acum să vedem fiecare dintre scenarii în detaliu.

Scenariul 1: Cheia primară va fi implicit la

Index cluster
În acest caz vom crea doar cheia primară și când verificăm tipul de index creat pe tabel
vom observa că acesta a creat automat un index grupat peste el.

-- Case 1 Primary Key Defaults to Clustered Index

USE TempDB
GO
-- Create table
CREATE TABLE TestTable
(ID INT NOT NULL PRIMARY KEY,
Col1 INT NOT NULL)
GO
-- Check Indexes
SELECT OBJECT_NAME(OBJECT_ID) TableObject,
[name] IndexName,
[Type_Desc] FROM sys.indexes
WHERE OBJECT_NAME(OBJECT_ID) = 'TestTable'
GO
-- Clean up
DROP TABLE TestTable
GO

Scenariul 2: Cheia primară este definită ca

un index necluster
În acest caz, vom defini în mod explicit Cheia primară ca un index non-cluster și o va crea
ca un index non-cluster. Demonstrează că cheia primară poate fi un index non-cluster.

-- Case 2 Primary Key Non-clustered Index

USE TempDB
GO
-- Create table
CREATE TABLE TestTable
(ID INT NOT NULL PRIMARY KEY NONCLUSTERED,
Col1 INT NOT NULL)
GO
-- Check Indexes
SELECT OBJECT_NAME(OBJECT_ID) TableObject,
[name] IndexName,
[Type_Desc] FROM sys.indexes
WHERE OBJECT_NAME(OBJECT_ID) = 'TestTable'
GO
-- Clean up
DROP TABLE TestTable
GO
Scenariul 3: Cheia primară este implicită la
Index non-clustered cu o altă coloană
definită ca un index cluster
În acest caz, vom crea un index grupat pe o altă coloană, SQL Server va crea automat o
cheie primară ca index non-cluster, deoarece indexul grupat este specificat pe altă coloană.

-- Case 3 Primary Key Defaults to Non-clustered Index

USE TempDB
GO
-- Create table
CREATE TABLE TestTable
(ID INT NOT NULL PRIMARY KEY,
Col1 INT NOT NULL UNIQUE CLUSTERED)
GO
-- Check Indexes
SELECT OBJECT_NAME(OBJECT_ID) TableObject,
[name] IndexName,
[Type_Desc] FROM sys.indexes
WHERE OBJECT_NAME(OBJECT_ID) = 'TestTable'
GO
-- Clean up
DROP TABLE TestTable
GO

Scenariul 4: Cheia primară este implicită la

Index cluster, iar alt index este implicit la
Index neclustrat
În acest caz vom crea doi indici pe ambele tabele, dar nu vom specifica tipul de index pe
coloane. Când verificăm rezultatele, vom observa că Cheia primară este automat implicită
la Index Clustered și o altă coloană ca index Non-cluster.

-- Case 4 Primary Key and Defaults

USE TempDB
GO
-- Create table
CREATE TABLE TestTable
(ID INT NOT NULL PRIMARY KEY,
Col1 INT NOT NULL UNIQUE)
GO
-- Check Indexes
SELECT OBJECT_NAME(OBJECT_ID) TableObject,
[name] IndexName,
[Type_Desc] FROM sys.indexes
WHERE OBJECT_NAME(OBJECT_ID) = 'TestTable'
GO
-- Clean up
DROP TABLE TestTable
GO

Cred că exemplele de mai sus clarifică dacă există confuzii legate de indexul primar și
grupat.

Acum, iată întrebarea care mi se pune adesea care poate fi motivul pentru crearea cheii
primare și a cheii de index în cluster pe diferite coloane . Ei bine, există multe scenarii
în care acest lucru poate fi adevărat. Este posibil să aveți coloana SSN pe care doriți să o
creați ca cheie primară, dar nu doriți să o faceți ca o cheie de index în cluster, deoarece
aveți o coloană de identitate în creștere în mod unic care se potrivește cel mai bine nevoilor
dvs. pentru acel tabel (din nou acesta este doar un exemplu – poți argumenta și exact
invers). Sunteți binevenit să continuați discuția pe acest subiect în câmpul de comentarii
sau într-o postare de blog dedicată pe care am scris-o cu ani în urmă aici. Există puține
comentarii foarte bune acolo – cred că acea postare de blog este acum o mină de aur
pentru a înțelege acest concept.