Kata-katanya agak logis dan Anda akan mempelajarinya dengan cepat. :)
Dalam istilah awam, SEEK menyiratkan mencari lokasi yang tepat untuk catatan, yang dilakukan SQL Server ketika kolom yang Anda cari diindeks, dan filter Anda (kondisi WHERE) cukup akurat.
SCAN berarti rentang baris yang lebih besar tempat perencana eksekusi kueri memperkirakan lebih cepat untuk mengambil seluruh rentang dibandingkan dengan mencari setiap nilai secara individual.
Dan ya, Anda dapat memiliki beberapa indeks di bidang yang sama, dan terkadang itu bisa menjadi ide yang sangat bagus. Mainkan dengan indeks dan gunakan perencana eksekusi kueri untuk menentukan apa yang terjadi (pintasan di SSMS:Ctrl + M). Anda bahkan dapat menjalankan dua versi kueri yang sama dan perencana eksekusi akan dengan mudah menunjukkan kepada Anda berapa banyak sumber daya dan waktu yang digunakan oleh masing-masing versi, sehingga pengoptimalan menjadi cukup mudah.
Tetapi untuk sedikit memperluas ini, katakanlah Anda memiliki tabel alamat seperti itu, dan memiliki lebih dari 1 miliar catatan:
CREATE TABLE ADDRESS
(ADDRESS_ID INT -- CLUSTERED primary key ADRESS_PK_IDX
, PERSON_ID INT -- FOREIGN KEY, NONCLUSTERED INDEX ADDRESS_PERSON_IDX
, CITY VARCHAR(256)
, MARKED_FOR_CHECKUP BIT
, **+n^10 different other columns...**)
Sekarang, jika Anda ingin menemukan semua informasi alamat orang 12345, indeks pada PERSON_ID sempurna. Karena tabel memiliki banyak data lain pada baris yang sama, akan menjadi tidak efisien dan menghabiskan banyak ruang untuk membuat indeks nonclustered untuk mencakup semua kolom lain serta PERSON_ID. Dalam hal ini, SQL Server akan mengeksekusi indeks SEEK pada indeks di PERSON_ID, kemudian menggunakannya untuk melakukan Pencarian Kunci pada indeks berkerumun di ADDRESS_ID, dan dari sana mengembalikan semua data di semua kolom lain pada baris yang sama.
Namun, katakanlah Anda ingin mencari semua orang di sebuah kota, tetapi Anda tidak memerlukan informasi alamat lainnya. Kali ini, cara yang paling efektif adalah dengan membuat indeks di CITY dan menggunakan opsi INCLUDE untuk mencakup PERSON_ID juga. Dengan begitu, pencarian/pemindaian indeks tunggal akan mengembalikan semua informasi yang Anda butuhkan tanpa perlu memeriksa indeks CLUSTERED untuk data PERSON_ID pada baris yang sama.
Sekarang, katakanlah kedua kueri itu diperlukan tetapi masih agak berat karena 1 miliar catatan. Tapi ada satu permintaan khusus yang harus sangat cepat. Kueri itu menginginkan semua orang di alamat yang telah MARKED_FOR_CHECKUP, dan yang harus tinggal di New York (abaikan apa pun artinya pemeriksaan, itu tidak masalah). Sekarang Anda mungkin ingin membuat indeks ketiga yang difilter pada MARKED_FOR_CHECKUP dan CITY, dengan INCLUDE mencakup PERSON_ID, dan dengan filter yang mengatakan CITY ='New York' dan MARKED_FOR_CHECKUP =1. Indeks ini akan sangat cepat, karena hanya mencakup kueri yang memenuhi kondisi persis tersebut, dan karena itu memiliki sebagian kecil data yang harus dilalui dibandingkan dengan indeks lainnya.
(Penafian di sini, ingatlah bahwa perencana eksekusi kueri tidak bodoh, ia dapat menggunakan beberapa indeks nonclustered bersama-sama untuk menghasilkan hasil yang benar, jadi contoh di atas mungkin bukan yang terbaik yang tersedia karena sangat sulit untuk membayangkan kapan Anda akan membutuhkannya. 3 indeks berbeda yang mencakup kolom yang sama, tapi saya yakin Anda mengerti.)
Jenis indeks, kolomnya, kolom yang disertakan, urutan penyortiran, filter, dll. bergantung sepenuhnya pada situasi. Anda perlu membuat indeks penutup untuk memenuhi beberapa jenis kueri yang berbeda, serta indeks khusus yang dibuat khusus untuk kueri tunggal dan penting. Setiap indeks memakan ruang pada HDD sehingga membuat indeks yang tidak berguna adalah pemborosan dan membutuhkan perawatan ekstra setiap kali model data berubah, dan membuang waktu dalam operasi defragmentasi dan pembaruan statistik ... jadi Anda tidak ingin hanya menampar indeks pada semuanya baik.
Bereksperimen, pelajari, dan kerjakan mana yang paling sesuai dengan kebutuhan Anda.
