3.

INDEX DAN OPTIMASI QUERY

Objektif :
Setelah menyelesaikan materi ini, mahasiswa dapat melakukan hal sebagai berikut :
1. Mengetahui tentang Index dan Transact SQL
2. Mengubah Informasi Index
3. Mengetahui petunjuk penggunaan Index
4. Mengetahui Transact SQL dan hubungannya dengan Optimasi Query

1
3.1. Index
SQL Server menggunakan Index untuk pengaksesan data dengan cepat. Index dapat
dianalogikan dengan index pada buku. Ketika mencari sebuah topik dalam sebuah buku, digunakan
index buku untuk menemukan halaman sesuai dengan topik yang dicari. Demikian halnya, ketika
dilakukan pencarian sebuah baris dari sebuah SQL Server tabel menggunakan sebuah index untuk
menemukan lokasi fisik dari baris tersebut.
Index dalam SQL Server dibangung menggunakan struktur data b-tree, seperti namanya,
sebuah b-tree mempunyai struktur seperti pohon dimana semua node paling bawah (node daun)
memiliki jumlah level yang sama jauhnya dari puncak (root) pohon. Properti ini terus dipelihara
walaupun ketika data baru ditambahkan atau dihapus dari kolom yang dilakukan index.
Gambar 3.1 mengilustrasikan struktur dari b-tree dan di akses langsung ke baris tabel
karyawan (emp) dimana kolom emp_no bernilai 25348 (Diasumsikan bahwa tabel karyawan
memiliki index pada kolom emp_no). Pada gambar tersebut dapat dilihat bahwa setiap b-tree
terdiri dari node akar (root), node daun (leaf) dan nol atau lebih node diantara akar dan daun.
Pencarian nilai data 25348 dapat dijalankan sebagai berikut: diawali dari akar b-tree, proses
mencari untuk nilai lebih besar dari atau sama dengan nilai yang akan diambil. Oleh karena itu,
nilai 29348 diambil dari node akar, kemudian nilai 28559 dimasukkan dari level menengah dan
nilai yang dicari yaitu 25348 diambil pada level daun. Dengan bantuan pointer, baris yang sesuai
akan diambil (sebagai alternative, tetapi serupa, metode pencarian akan mencari untuk nilai
terkecil atau sama dengan).
Tabel sistem yang menyimpan informasi mengenai index adalah sysindexes. Sysindexes
berisikan diantaranya, baris untuk masing-masing index dari database saat ini, juga sebuah system
procedure, sp_helpindex, yang berisikan index dari sebuah tabel.

2
 Gambar 3.1. B-tree untuk tabel karyawan

3.1.1. Clustered dan Non Clustered Index

Clustered index menentukan urutan fisik dari data dalam sebuah tabel. SQL Server
mengijinkan pembuatan single clustered index per tabel, karena baris-baris dalam sebuah tabel
tidak dapat secara fisik diurutkan lebih dari satu cara.
Clustered index dapat diorganisasikan dalam sysindexes tabel sistem melalui nilai 1 dan
indid (index id) kolom. Terdapat kolom lain dari tabel yang sama –root- yang merupakan titik
teratas clusterd index. SQL Server mengarah kebawah dari root struktur b-tree ke node daun yang
dihubungkan bersama-sama dalam dpubly linked list. Properti dari struktur clustered index adalah
node daunnya berisikan halaman data.
Clustered index secara implicit dibangun untuk setiap tabel, dimana didefinisikan sebagai
kunci utama menggunakan primary key constraint, juga setiap clustered index dalam SQL Server
adalah unik secara default, setiap nilai data dapat muncul hanya sekali dalam sebuah kolom dimana
clustered index didefinisikan. Jika sebuah clustered index dibangun pada kolom nonunique kolom,
database sistem akan memaksa keunikan dengan menambahkan 4 byte identifier ke baris-baris
yang mempunyai nilai duplikat.
Non clustered index mempunyai struktur index yang sama dengan clustered index, dengan
dua perbedaan yang penting:

3
 1. Nonclustered index tidak dapat mengubah urutan fisik baris-baris dalam tabel
2. Level daun dari nonclustered index terdiri dari sebuah kunci index ditambahkan dengan
bookmark.
Urutan fisik baris-baris dalam sebuah tabel tidak akan berubah jika satu atau lebih
nonclustered index didefinisikan untuk tabel tersebut. Untuk setiap nonclusterd index, SQL Server
membuat sebuah struktur index tambahan yang disimpan dalam halaman index.
Bookmark dari nonclustered index menunjukkan dimana penemukan baris yang sesuai
dengan kunci index. Bagian bookmark dari kunci index dapat mempunyai dua bentuk, tergantung
pada bentuk tabel yaitu apakah tabel adalah clusterd tabel atau heap.

3.2. Index dan Statemen Transact-SQL

Bahasa Transact-SQL mendukung dua statement DDL yang berhubungan dengan Index :
CREATE INDEX dan DROP INDEX. Statemen CREATE INDEX membuat sebuah index untuk
tabel tertentu. Bentuk umum dari statemen ini adalah :

CREATE [UNIQUE][CLUSTERED | NONCLUSTERED] INDEX nama_index

ON {nama_tabel | nama view } (column1 [ASC | DESC]
[{,column2 [ASC | DESC]} ..])
[WITH
[FILLFACTOR=n]
[[,] IGNORE_DUP_KEY]
[[,] PAD_INDEX]
[[,] DROP_EXISTING]
[[,] STATISTICS_NORECOMPUTE]]
[ON file_group]

nama_index mengidentifikasi nama index yang dibuat. Sebuah index dapat dibentuk untuk satu
atau lebih kolom dari tabel tunggal yang disebut nama_tabel. Kolom1, kolom2, …. Adalah nama
kolom dimana index dibuat.
Sebuah index dapat tunggal atau komposit. Index komposit dibangun pada lebih dari satu
kolom. Setiap index komposit mempunyai batasan tertentu tergantung pada panjang dan jumlah
kolom yang bersangkutan. Ukuran maksimum untuk index adalah 900 bytes, yang berarti dapat
berisi sampai dengan 16 kolom.

4
 UNIQUE option menentukan bahwa setiap nilai data yang dapat muncul hanya sekali
dalam kolom yang diindex. Untuk index komposit unique, kombinasi nilai data dari semua kolom
dalam setiap baris harus unik. Jika UNIQUE tidak ditentukan, diperbolehkan terdapat nilai
duplikat.
CLUSTERED option menentukan sebuah index dicluster. NONCLUSTERED option
(default) menentukan bahwa index tidak merubah urutan baris-baris dalam tabel. SQL Server
mengijinkan maksimum 249 index nonclustered per tabel.
FILLFACTOR = n menentukan prosentase penyimpanan untuk masing-masing halaman
index pada waktu index dibuat. FILLFACTOR dapat berisikan nilai dari 1 sampai 100. Jika nilai
dari n adalah 100, setiap halaman index akan 100% terisi artinya halaman index saat ini tidak akan
memiliki tempat untuk penambahan baris-baris baru. Oleh karenanya nilai ini direkomendasikan
hanya untuk tabel statis.
PAD_INDEX option secara kuat terhubung dengan FILLFACTOR option. FILLFACTOR
utamanya menentukan prosentase ukuran yang masih tersedia pada halaman index daun. PAD
INDEX option menentukan tempat untuk dibiarkan terbuka pada setiap halaman index
intermediate dari b-tree.
Selain statemen DBCC DBREINDEX, dapat pula digunakan prosedur sistem sp_configure
untuk mengubah nilai FILLFACTOR option. Prosedur sistem sp_configure menampilkan atau
mengubah beberapa pilihan konfigurasi server.
IGNORE_DUP_KEY option menyebabkan sistem mengabaikan usaha untuk memasukkan
nilai duplikat pada kolum terindex. Option ini seharusnya digunakan hanya untuk menghindari
pemberhentian sebuah transaksi panjang dalam kasus ketika statemen INSERT memasukkan data
duplikat dalam kolom yag terindex. Jika option ini diaktifkan dan sebuah statemen INSERT
berusaha untu memasukkan baris-baris yang akan melanggar keunikan dari index, SQL Server
memuncuklan sebuah peringatan. SQL Server tidak memasukkan baris-baris yang akan
menambahkan nilai kunci duplikat, SQL Server hanya mengabaikan baris-baris tersebut dan
menambahkan sisa baris yang tidak duplikat.
DROP_EXISTING option mengijinkan untuk meningkatkan kinerja ketika membuat
kembali sebuah index clustered pada sebuah tabel yang juga mempunyai sebuah index
nonclustered. Option ini menentukan bahwa index clustered atau nonclustered akan dihapus dan
index yang telah ditentukan akan dibuat kembali.

5
 STATISTIC_NORECOMPUTE option menentukan bahwa statistik dari index yang
ditentukan tidak seharusnya dijalankan ulang secara otomatis. ON file_group option membuat
index yang ditentukan pada file grup tertentu.
SQL Server mendukung index dengan urutan menurun pada nilai kolom. ASC option
setelah nama kolom menentukan bahwa index dibuat dengan urutan menaik untuk nilai kolom,
sedangkan DESC menentukan urutan menurun.
Untuk membuat index baru dapat menggunakan Enterprise Manager. Caranya adalah
dengan memilih Tables dalam folder Database, klik kanan nama tabel pada panel detail, pilih All
Tasks dan klik Indexes. Dalam dialog box Manage Indexes, pilih New. Dialog box Create New
Index akan muncul. Dialog box berisikan semua option yang telah didiskusikan sebelumnya.

Contoh 3.1 (Lihat Video)

Buat sebuah index untuk kolom emp_no pada tabel employee.
CREATE INDEX i_empno ON employee(emp_no).

Contoh 3.2 (Lihat Video)

Buat index komposit i_empno_pro untuk kolom emp_no dan project_no pada tabel works_on.
Nilai gabungan pada kedua kolom harus unik. Delapan puluh persen untuk setiap halaman daun
index seharusnya terisi.
CREATE UNIQUE INDEX i_empno_pro
ON works_on (emp_no, project_no)
WITH FILLFACTOR=80

Contoh 3.3 (Lihat Video)

Untuk setiap karyawan, hapus baris dari tabel works_on yang tidak berisikan tanggal masuk terkini
untuk sebuah proyek.

USE company
GO
SELECT emp_no, MAX(enterdate) max_date
FROM works_on
GROUP BY emp_no

6
 HAVING COUNT(*)>1
DELETE works_on
FROM works_on
WHERE works_on.emp_no=works_on.emp_no
AND works_on.enterdate < works_on.enterdate

Contoh 3.4 (Lihat Video)

Hapus index yang telah dibuat pada contoh 3.1
DROP INDEX employee.i_empno

3.3. Mengubah Informasi Index

Untuk mengubah informasi mengenai index yang ada saat ini, dapat menggunakan fitur
SQL Server berikut ini :
1. Tabel sistem sysindexes
2. Procedure sistem sp_helpindex
3. Enterprise Manager

Tabel sistem sysindexes muncul pada database master dan setiap database yang didefinisikan oleh
pengguna. Sysindexes berisikan baris untuk setiap index dan baris untuk setiap tabel tanpa
clustered index. Tabel 3.1 menunjukkan kolom yang paling penting dari sysindexes.

Tabel 3.1 Kolom dalam sysindexes

Kolom Deskripsi
name Nama dari sebuah index (untuk indid >0 dan indid >=250) atau sebuah tabel
Id Objek ID (dari sysobjects) dari sebuah tabel (untuk indid >0 dan
indid>=250). Untuk indid 0 atau 255, ID dari tabel dimana index dibuat
Indid Nomor identifikasi dari sebuah index : indid =0 menunjukkan sebuah table,
indid=1 menunjukkan clustered index, indid>1 dan <=250 menunjukkan
nonclustered index, dan indid=255 menunjukkan sebuah masukan untuk
tabel yang berupa data text/gambar

7
 Dpages Menampilkan jumlah halaman daun index yang telah digunakan, jika
masukan pada tabel sistem ini menunjukkan sebuah nonclustered index
(contohnya jika 1<indid<=250. Jika indid=0 atau indid=1, dpages adalah
jumlah halaman data yang digunakan)
Reserved Jumlah total halaman yang dipesan untuk semua index dan data tabel (jika
indid = 0 atau 1). Jika <indi<=250 jumlah halaman yang dipesan untuk
sebuah index
Used Jumlah total halaman digunakan untuk semua index dan tabel data (jika indid
= 1 atau 1). Jika 1<indid<=250, jumlah halaman yang digunakan untuk index
firstIAM Pointer ke halaman IAM pertama yang digunakan untuk melacak halaman
index
First Pointer ke halaman pertama atau halaman root

Store procedure sistem sp_helpindex menampilkan semua index pada sebuah tabel dalam bentuk
kolom statistic. Sintaks dari prosedur adalah:
Sp_helpindex [@db_object = ] ‘table_name’
Untuk mengubah informasi mengenai index yang ada ( atau untuk membuat index baru )
menggunakan Enterprise Manager, pilih database dalam folder Databases dan pilih TABLES.
Kilik kanan tabel yang akan dilihat informasinya, pilih All Taksks dan pilih Manages Indexes.
Dalam dialog box Manage Indexes, dapat dilakukan hal berikut ini:
1. Menampilkan index yang ada pada tabel yang dipilih
2. Membuat index baru
3. Menghapus index

3.4. Index dan Kunci

Seperti halnya index, kunci juga merupakan bagian dari bahasa Transact-SQL, sebelum
mempelajari hubungan antar index dan kunci, beberapa tipe kunci akan dijelaskan. Kunci-kunci
berikut ada pada model data relasional:
1. Kunci kandidat
2. Kunci Utama

8
 3. Kunci Tamu
Kunci utama dari sebuah tabel adalah sebuah kolom atau grup kolom dimana nilainya berbeda
untuk setiap baris. Terkadang lebih dari satu kolom atau grup kolom dari tabel mempunyai nilai
unik. Dalam kasus ini, semua kolom atau grup kolom yang memenuhi sebagai kunci utama disebut
kunci kandidat. Kunci tamu adalah sebuah kolom atau grup kolom dalam satu table berisikan nilai
yang sesuai dengan nilai kunci utama pada tabel yang sama atau tabel lain.
Sebuah index unik untuk kunci utama dan setiap kunci kandidat dari tabel seharusnya ada,
juga setiap kolom yang mewakilkan kunci utama atau kunci kandidat seharusnya berisikan
constraint NOT NULL. Persyaratan ini berasal dari model relasional: setiap kunci utama atau kunci
kandidat dipandang sebagai fungsi matematik yang mendefinisikan setiao elemen secara unik.
Untuk setiap kunci tamu, pembuatan index nonunique diperlukan ( join kolom dalam tabel
yang direferensikan mewakilkan sebuah kunci tamu). Pembuatan sebuah index untuk kunci tamu
secara signifikan mengurangi waktu eksekusi yang diperlukan untuk operasi join yang bersesuaian
(spesifikasi UNIQUE untuk kasus ini akan aslah, karena kunci tamu mengijinkan nilai data
duplikat).

Contoh 3.5 (Lihat Video)

CREATE INDEX i_emp_deptno ON employee(dept_no)
CREATE INDEX i_works_empno ON works_on(emp_no)
CREATE INDEX i_works_pro_no ON works_on(project_no)

3.5. Petunjuk untuk Pembuatan Index

SQL Server tidak mempunyai batasan jumlah index, namun menyarankan untuk
membatasi index untuk beberapa alasan. Pertama, setiap index menggunakan sejumlah media
penyimpanan, oleh karenanya terdapat kemungkinan untuk jumlah halaman index melebihi jumlah
halaman data pada sebuah database. Kedua, hal yang kontras dengan kelebihan dari penggunaan
sebuah index untuk pengambilan data, penyisipan baris-baris kedalam sebuah tabel dengan kolom
diinedx menyebabkan kehilangan kinerja karena pohon index harus dimodifikasi (hal sama juga
untuk penghapusan baris).
Berikut ini rekomendasi umum untuk pembuatan sebuah index ;
1. Klausa WHERE

9
 Jika klausa WHERE dalam statemen SELECT berisikan kondisi pencarian dengan kolom
tunggal, sebuah index pada kolom ini akan dibuat. Penggunaan sebuah index secara khusus
direkomendasikan jika selektifitas dari kondisi tinggi (contoh rasio kecil). Selektivitas
kondisi didefinisikan sebagai rasio jumlah baris kondisi yang memenuhi atau sesuai
dengan jumlah baris dalam tabel. Pemrosesan yang paling berhasil dari pengambilan
dengan kolom diindex akan dicapai jika seletifitas kondisi adalah 5 persen atau kurang.
Kolom seharusnya tidak diindex jika seletifitas dari kondisi secara tetap 80 persen atau
lebih. Pada kasus ini, penambahan operasi I/O akan diperlukan untuk keberadaan halaman
index, yang akan mengurangi waktu penyimpanan yang diperoleh dengan akses langsung.
Dalam kasus tertentu ini, scan tabel akan lebih ceoat (dan SQL Server query optimizer
biasanya akan memilih table scan, sehingga index tidak berguna).
2. Operator AND
Jika kondisi pencarian dalam klausa WHERE yang sering digunakan berisikan satu atau
lebih operator AND, sangat baik untuk membuat index komposit yang menyertakan semua
kolom dari tabel yang dispesifikasikan dalam klausa FROM dalam statemen SELECT.
Contoh 3.9 menunjukkan pembuatan index komposit yang menyertakan semua kolom
yang dispesifikasikan dalam klausa WHERE pada statemen SELECT.

Contoh 3.6 (Lihat Video)

CREATE INDEX i_woks ON works_on(emp_no,enter_date)
SELECT *
FROM works_on
WHERE emp_no=29346 AND enter_date=’12.15.1997’

Operator AND dalam statemen SELECT pada contoh 3.6 berisikan dua kondisi, dengan
demikian, kedua kolom yang muncul di setiap kondisi harus diindeks menggunakan indeks
komposit.

3. Operator Join

10
 Pada kasus operasi Join, direkomendasikan untuk setiap join kolom diindex. Join kolom
seringkali mewakilkan kunci utama dari satu tabel dan kunci tamu yang bersesuaian dari tabel lain
atau tabel yang sama. Kedua kolom seharusnya diindex.

Contoh 3.7 (Lihat Video)

SELECT emp_lname, emp_fname
FROM employee, works_on
WHERE employee.emp_no=works_on.emp_no
AND enter_date = ’10.15.1998’

Contoh 3.7, sangat direkomendasikan membuat dua index terpisah untuk kolom emp_no dalam
tabel employee dan tabel works_on. Direkomendasikan juga index tambahan seharusnya dibuat
untuk kolom enter_date.

Rekomendasi-rekomendasi ini merupakan aturan praktis umum. Rekomendasi inipada akhirnya

tergantung pada bagaimanna database akan digunakan dalam produksi dan kolom mana yang
paling sering digunakan. Sebuah index pada sebuah kolom yang tidak pernah digunakan akan
menjadi tidak produktif.

3.6. Kriteria Umum untuk Meningkatkan Efisiensi

Pada bagian ini akan dijelaskan bagaimana style pemrograman dapat mempengaruhi
efisiensi dari aplikasi database. Sebuah komponen SQL Server yang disebut query optimizer
menyediakan solusi terhadap masalah bagaimana setiap query seharusnya dijalankan (sebagai
contoh, index apakah yang seharusnya digunakan, dalam urutan apakah tabel seharusnya diakses,
bagaimana join seharusnya diimplementasikan). Solusi ini disebut dengan rencana ekesusi query
(query execution plan), dan tugas utama dari optimizer adalah memilih rencana optimal. Terkadang
informasi yang tersedia untuk optimizer tidak sesuai untuk menentukan rencana optimal. Oleh
karena itu sangat penting untuk mengetahui bagaimana programmer dapat meningkatkan efisiensi
dari aplikasinya. Berikut ini , beberapa isu akan didiskusikan.

11
1. Join vs Correlated Subquery
Setiap query biasanya dapat diekspresikan dengan satu statemen SELECT dari beberapa
perbedaan staetmen, tetapi mempunyai makna yang sama. Sebagai contoh, setiap operasi
join dapat diekspresikan menggunakan correlated subquery begitu juga sebaliknya.
Metode ini berbeda dimana operasi join lebih efisien dibandingkan dengan correlated
subquery. Contoh 3.8 menunjukkan perbedaan tersebut.

Contoh 3.8
Dapatkan nama terakhir dari semua karyawan yang bekerja pada project p3.

Solusi A:
SELECT emp_lname
FROM employee, works_on
WHERE employee.emp_no=works_on.emp_no
AND project_no=’p3’

Solusi B:
SELECT emp_lname
FROM employee, works_on
WHERE ‘p3’ IN (SELECT project_no
FROM works_on
WHERE employee.emp_no=works_on.emp_no)

Kinerja solusi A lebih baik daripada kinerja solusi B. Inner Query dalam solusi B pada
contoh 3.8 harus dievaluasi beberapa kali karena inner query berisikan kolom emp_no,
yang dimiliki oleh tabel employee dalam outer query, sehingga nilai kolom emp_no
berubah setiap kali SQL Server memeriksa baris yang berbeda dari tabel employee dalam
outer query. Join dalam solusi A bekerja lebih cepat karena Join mengevaluasi semua nilai
dari kolom project_no dari tabel works_on hanya satu kali.

2. Incomplete Statemen
Secara praktek, ada kemungkinan programmer menspesifikasikan statement SQL secara
tidak lengkap. Statement semacam itu tidak hanya salah tetapi berpengaruh sangat kuat

12
 terhadap efisiensi dari keseluruhan aplikasi. Contoh khususnya adalah Cartesian product
dari dua table.
Hasil dari Cartesian product berisikan setiap kombinasi baris-baris dari dua tabel. Sebagai
contoh, jika satu tabel berisikan 10000 baris dan tabel kedua 100 baris, hasil dari Cartesian
product kedua tabel akan menjadi sebuah tabel dengan 1 juta baris.
Penggunaan Cartesian product dalam praktek adalah sangat tidak biasa, terkadang
pengguna secara tidak sengaja membuat Cartesian produk dari dua tabel ketika mereka
lupa untuk menyertakan kondisi join dalam klausa WHERE dari statemen SELECT. Pada
kasus ini, pengguna mempunyai sebuah statemen SELECT yang tidak lengkap dimana
kondisi join diabaikan. Secara umum, jika suatu query mengakses n tabel yang berbeda,
seharusnya mempunyai paling sedikit n-1 kondisi join berelasi ke semua table untuk
menghidari Cartesian product.

3. Operator LIKE
LIKE membandingkan nilai dari sebuah kolom dengan suatu pola tertentu. Jika kolom ini
berasosiasi dengan sebuah index, pncarian untuk karakter string ditampilkan dengan index
yang ada. Kondisi berdasarkan wildcard pada posisi awal memaksa SQL Server untuk
menjalankan setiap nilai dalam kolom, sehingga index yang ada tidak digunakan. Alasan
bahwa index bekerja dengan cepat menentukan apakah nilai yang diminta lebih besar atau
kurang dari nilai yang ada pada berbagai nodes b-tree. Jika karakter awal dari nilai yang
diinginkan tidak dispesifikasikan, maka perbandingan ini tidak dapat dilakukan.
Contoh 3.9
Dapatkan nomor karyawan untuk semua karyawan yang naa akhirnya diakhiri dengan kata
es.
SELECT emp_no
FROM employee
WHERE emp_lname LIKE ‘%es’

Query pada contoh 3.9, tersebut tidak mungkin untuk diproses, walaupun ada index untuk
kolom emp_lname. Alasannya adalah bahwa karakter di awal nilai data tidak dikenal dalam
kondisi pencarian di klausa WHERE.

13
3.7. Statemen Transact-SQL dan Query Performance
SQL Server mendukung dua statemen yang memungkinkan optimasi query:
1. UPDATE STATISTICS
2. SET
Statistik dalam tabel sistem tidak diupdate secara konstan. Statement UPDATE
STATISTICS memperbaharui informasi mengenai distribusi nilai kunci dalam index yang
dispesifikasi. Modifikasi informasi menggunakan statemen UPDATE STATISTIC seharusnya
diproses oleh pengguna dalam kasus sebagai berikut:
a. Mengubah beban awal data
b. Mengubah pelaksanaan statemen DML (INSERT, UPDATE atau DELETE) yang
mempengaruhi sejumlah besar baris
Di samping itu, statemen UPDATE STATISTICS secara otomatis berjalan ketika kita
membuat atau membuat ulang sebuah index pada tabel yang telah berisi data. Statemen UPDATE
STATISTICS dieksekusi oleh SQL Server secara periodik sebagai data dalam perubahan tabel.
Statemen kedua, SET memiliki beberapa opsi. Beberapa opsi ini digunakan query optimasi
dan beberapa untuk tujuan berbeda. Opsi berikut digunakan untuk query optimasi:
1. SHOWPLAN_TEXT
2. SHOWPLAN_ALL
3. NOEXEC
4. FORCEPLAN
5. ROWCOUNT
6. STATSTICS IO
7. STATISTICS TIME
Secara umum, ON mengaktifasi sebuah pilihan, sedangkan OFF menonaktifkan sebuah
pilihan. Pengguna menjalankan sebuah query dapat menampilkan rencana eksekuasi tekstual untuk
query tersebut dengan mengaktifkan SHOWPLAN_TEXT atau SHOWPLAN_ALL sebelum
query masuk ke statemens SELECT yang berkorespondensi. Opsi SHOWPLAN_ALL
menampilkan informasi detail yang sama mengenai rencana eksekusi yang dipilih utnuk query
sebagai SHOWPLAN_TEXT dengan penambahan estimasi kebutuhan sumberdaya untuk
statemen tersebut.
Statemen berikut menunjukkan penggunaan opsi SET SHOWPLAN_TEXT

14
 SET SHOWPLAN_TEXT ON
GO
SELECT employee.dept_no
FROM employee, works_on
WHERE employee.emp_no = works_on.emp_no
AND works_on.project_no=’p1’

3.8. Query Optimizer

Sebuah query biasanya dapat dikerjakan dalam beberapa cara berbeda tetapi mempunyai
makna yang sama. Query optimizer membuat beberapa rencana eksekusi query atau
langkahlangkah tertentu untuk mengerjakan sebuah query. Setelah itu, query optimizer
menetapkan biaya dari setiap rencana dan memilih rencana dengan biaya terendah (Hal ini disebut
dengan systematic query optimization).
Query optimizer selain menggunakan estimasi biaya untuk memilih solusi terbaik, juga
menggunakan aturan heuristic untuk meningkatkan kinerja dari eksekusi dari sebuah query.
Keberadaan dari aturan heuristic didasarkan pada fakta bahwa setiap query dapat dibangun
menggunakan beberapa solusi.

3.8.1 Optimizer Statistic

Keberadaan index pada kolom dalam query mengakibatkan pemilihan rencana eksekusi
tertentu dan oleh karena itu kinerja dari query. Selektifitas apakah index yang ada akan digunakan
oleh optimizer tergantung pada pemilihan dan tipe indexnya. Jika selektifitas sebuah index tinggi,
yaitu hanya beberapa baris yang diidentifikasi oleh nilai kunci index, maka index biasanya
digunakan Pertanyaannya adalah: bagaiman SQL Server menentukan pemilihan dari sebuah index.
Optimizer menggunakan statistic khusus disimpan untuk sebuah index untuk menentukan
seletifitas. Statistik ini disebut statistic distribusi, dan statistic ini menggambarkan seletifitas dan
distribusi dari nilai kunci pada sebuah index. Statistik berikut disimpan untuk tabel dan indexnya
yang digunakan oleh optimizer:
1. Jumlah baris dalam tabel
2. Jumlah halaman yang digunakan untuk menyimpan data
3. Jumlah langkah distribusi

15
 4. Jumlah baris sample untuk statistic
Contoh 3.11 menunjukkan bagaiman keputusan SQL Server optimizer dipengaruhi oleh
selektifitas kolom yang berbeda dalam klausa WHERE.
Contoh 3.11
Select * from works_on
Where enter_date =’01/01/1998’
And job=’Analyst’

Asumsikan bahwa tabel works_on mempunyai index untuk kolom enter_date dan job, index
manakah yang pertama akan digunakan? Misalnya, katakanlah kedua index mempunyai statistic
berikut:
Jumlah baris : 100,000
Estimasi jumlah bari (untuk works_on.enter_date) = 100
Estimasi jumlah baris (untuk works_on.job)=40,000

Menggunakan statistic ini, optimizer memperkirakan bahwa selektifitas dari kolom enter_date
adalah 0.1% (100/100,000) dan selektifitas dari kolom job adalah 405. Dari kalkulasi ini, optimizer
biasanya akan memilih rencana eksekusi berdasarkan pada index untuk kolom enter_date, karena
selektifitas kolom tersebut secara signifikan lebih tinggi dari kolom job.

3.9. DBCC Command dan Index

DBCC menentukan grup dari statemen yang digunakan untuk memeriksa konsistensi
database secara fisik dan logis (beberapa dari DBCC juga memperbaiki masalah database).
Terdapat dua statemen DBCC yang berhubungan dengan index :
1. DBCC DBREINDEX
2. DBCC UPDATEUSAGE

Statemen DBCC DBREINDEX membangun kembali indez untuk sebuah tabel atau semua
index yang didefinisikan untuk sebuah tabel. Dengan mengijinkan index untuk membangun
kembali secara dinamis, maka tidak perlu untuk mengahpus dan membuatnya kembali. Hal ini

16
sangat menguntungkan jika index dibuat secara implicit menggunakan integrity constrain
PRIMARY KEY dan UNIQUE. Pada kasus tersebut, tidak perlu menghapus dan membuat kembali
constrain.
Statement DBCC UPDATEUSAGE memperbaiki kolom rows, used, reserved dan dpages
dari tabel sysindexes untuk tabel dan index clustered. Ukuran informasi tidak di maintain untuk
index nonclusteres. Jika tidak terdapat ketidakakurasian dalam sysindexs, DBCC
UPDATEUSAGE tidak menghasilkan data. Jika ketidakakurasian ditemukan dan diperbaiki
dengan opsi WITH NO_INFOMSGS tidak digunakan, UPDATEUSAGE menghasilkan baris dan
kolom yang telah diupdate dengan sysindexes.

17