Seperti yang dikatakan Remus tergantung pada beban kerja Anda.
Saya ingin membahas aspek yang menyesatkan dari jawaban yang diterima.
Untuk kueri yang melakukan pencarian kesetaraan pada semua kolom dalam indeks, tidak ada perbedaan yang signifikan.
Di bawah ini membuat dua tabel dan mengisinya dengan data yang identik. Satu-satunya perbedaan adalah bahwa salah satu memiliki kunci yang dipesan dari yang paling selektif dan yang lainnya terbalik.
CREATE TABLE Table1(MostSelective char(800), SecondMost TINYINT, Least CHAR(1), Filler CHAR(4000) null);
CREATE TABLE Table2(MostSelective char(800), SecondMost TINYINT, Least CHAR(1), Filler CHAR(4000) null);
CREATE NONCLUSTERED INDEX MyINDX on Table1(MostSelective,SecondMost,Least);
CREATE NONCLUSTERED INDEX MyINDX2 on Table2(Least,SecondMost,MostSelective);
INSERT INTO Table1 (MostSelective, SecondMost, Least)
output inserted.* into Table2
SELECT TOP 26 REPLICATE(CHAR(number + 65),800), number/5, '~'
FROM master..spt_values
WHERE type = 'P' AND number >= 0
ORDER BY number;
Sekarang melakukan kueri terhadap kedua tabel ...
SELECT *
FROM Table1
WHERE MostSelective = REPLICATE('P', 800)
AND SecondMost = 3
AND Least = '~';
SELECT *
FROM Table2
WHERE MostSelective = REPLICATE('P', 800)
AND SecondMost = 3
AND Least = '~';
... Keduanya menggunakan denda indeks dan keduanya diberi biaya yang sama persis.
Seni ASCII dalam jawaban yang diterima sebenarnya bukan bagaimana indeks disusun. Halaman indeks untuk Table1 diwakili di bawah ini (klik gambar untuk membuka dalam ukuran penuh).
Halaman indeks berisi baris yang berisi seluruh kunci (dalam hal ini sebenarnya ada kolom kunci tambahan yang ditambahkan untuk pengidentifikasi baris karena indeks tidak dinyatakan sebagai unik tetapi yang dapat diabaikan informasi lebih lanjut tentang ini dapat ditemukan di sini ).
Untuk kueri di atas SQL Server tidak peduli dengan selektivitas kolom. Itu melakukan pencarian biner dari halaman root dan menemukan bahwa Key (PPP...,3,~ ) adalah >=(JJJ...,1,~ )dan < (SSS...,3,~ )karena itu harus membaca halaman 1:118. Kemudian melakukan pencarian biner dari entri kunci pada halaman itu dan menemukan halaman daun untuk melakukan perjalanan.
Mengubah indeks dalam urutan selektivitas tidak memengaruhi jumlah perbandingan kunci yang diharapkan dari pencarian biner atau jumlah halaman yang perlu dinavigasi untuk melakukan pencarian indeks. Paling-paling itu mungkin sedikit mempercepat perbandingan kunci itu sendiri.
Kadang-kadang memesan indeks yang paling selektif terlebih dahulu akan masuk akal untuk pertanyaan lain dalam beban kerja Anda.
Misalnya jika beban kerja berisi kueri dari kedua formulir berikut.
SELECT * ... WHERE MostSelective = 'P'
SELECT * ...WHERE Least = '~'
Indeks di atas tidak mencakup keduanya. MostSelectivecukup selektif untuk membuat rencana dengan pencarian dan pencarian bermanfaat tetapi permintaan terhadap Leasttidak.
Namun skenario ini (pencarian non-cakupan indeks pada subset kolom utama dari indeks komposit) hanya satu kelas query yang mungkin dapat dibantu oleh indeks. Jika Anda tidak pernah benar-benar mencari MostSelectivesendiri atau kombinasi dari MostSelective, SecondMostdan selalu mencari dengan kombinasi ketiga kolom maka keuntungan teoretis ini tidak berguna bagi Anda.
Sebaliknya, pertanyaan seperti
SELECT MostSelective,
SecondMost,
Least
FROM Table2
WHERE Least = '~'
ORDER BY SecondMost,
MostSelective
Akan terbantu dengan memiliki urutan terbalik dari yang biasa ditentukan - karena mencakup permintaan, dapat mendukung pencarian dan mengembalikan baris dalam urutan yang diinginkan untuk boot.
Jadi ini adalah saran yang sering diulang, tetapi paling tidak heuristik tentang manfaat potensial untuk pertanyaan lain - dan itu bukan pengganti untuk benar-benar melihat beban kerja Anda .