Jurnal Query

Salim, Kajian Proses Query ISSN 2085-3548

199

KAJIAN PROSES QUERY PADA SOFTWARE DATABASE My-SQL

(The Query Optimization Process In Database Software My-SQL)

Yeffriansjah Salim

Prodi D3 Manajemen Informatika STMIK Indonesia Banjarmasin

Jl P.Hidayatullah Banjarmasin Email: [email protected]

ABSTRACT

Computers play an important role in every aspect of life, used to store and retrieve data that

has large numbers in an efficient manner, usually called the managemet database systems (DBMS).

Facilities of the DBMS is able to access a single databasesimultaneously by many users, can

access data in a confined onlyto the user who has the right and replace the failure of the

systemswithout losing data integrity. Generally, the first interface (tree) to aDMBS is a high-

level query or data manipulation language. An example is SQL (Structure Query Language).

Reliability of a database system or the DBMS can be detected by the optimizer works his way in the

processing of SQL statements, statement made by the user and application programs. In the

optimizer, statement-statement that is processed by one of the many available methods

for obtaining the most optimal query plan will ultimately be up to answer queries with the

minimum accesstime. The process of finding the best query execution plan is called

the query optimization process.

Keywords : query, database My-SQL

PENDAHULUAN

Statement – statement (pernyataan-

pernyataan) dalam SQL dapat dihasilkan secara

langsung oleh user dengan menggunakan

command-command (perintah-perintah)

interface atau dengan sebuah program aplikasi.

Kehandalan dari suatu sistem database

atau DBMS dapat diketahui dari cara kerja

optimizer-nya dalam memproses statement-

statement SQL yang dibuat oleh user maupun

program-program aplikasinya. Di dalam

optimizer, statement-statement yang ada

diproses dengan salah satu cara dari banyak

cara yang ada untuk mendapatkan perencanaan

query yang paling optimal sehingga pada

akhirnya akan didapatkan jawaban query

dengan waktu akses yang paling minimum.

Proses untuk mencari perencanaan eksekusi

query yang terbaik inilah yang disebut dengan

proses optimisasi query.

Database Manajemen Sistem (DBMS)

adalah kumpulan dari program-program yang

membolehkan user untuk menciptakan dan

memelihara sebuah database. DBMS sudah

menjadi peralatan standar untuk melindungi

pengguna komputer dari bagian-bagian kecil

dalam pengelolaan secondary storage (hard

disk). DBMS didesain untuk meningkatkan

produktivitas dari aplikasi para programmer

dan untuk memberikan kemudahan

pengaksesan data oleh komputer.

mailto:[email protected]


200

Sebuah query yang diekspresikan dalam

sebuah bahasa query tingkat tinggi seperti SQL

mula-mula harus dibaca, diuraikan dan

disahkan (scanning, parsing, validating)1.

Query tersebut kemudian dibentuk menjadi

sebuah struktur data yang biasa disebut dengan

query tree.

METODE PENELITIAN

Teknik-teknik Optimisasi Query

Dua teknik tersebut adalah Heuristic

Optimization dan Cost Based optimization.

Heuristic Optimization

Heuristic Optimization atau yang

biasanya disebut dengan rule based

optimization adalah optimisasi query dengan

menggunakan aturan-aturan heuristik dan

dijalankan pada logical query plan (rencana

query secara logika) yang terdiri dari urutan

operasi-operasi relasional yang biasanya

digambarkan sebagai query tree. Query

Optimizer mendapatkan sebuah inisial plan dari

parser dan menggunakan aturan-aturan

heuristik untuk mentransformasikan sebuah

query ke dalam sebuah bentuk yang sama

sehingga dapat diproses dengan lebih efisien.

Adapun tujuan dari transformasi tersebut

adalah :

Standarisasi, yaitu mentransformasikan

sebuah query ke dalam sebuah bentuk

standar tanpa optimisasi.

Simplifikasi, yaitu mengeliminasi

kelebihan dalam sebuah query.

Ameliorasi, yaitu menyusun ekspresi-

ekspresi yang sudah dihasilkan dengan

baik untuk mengevaluasi bentuk.

Ada banyak aturan untuk

mentransformasikan operasi-operasi relasi

aljabar ke dalam suatu persamaan. Berikut ini

adalah beberapa aturan-aturan transformasi

untuk operasi-operasi relasi aljabar :

1. Pengurutan : sebuah pilihan kondisi

konjungtif dapat dipisahkan ke dalam

sebuah urut-urutan dari operasi-operasi

tersendiri : c1 AND c2 AND … AND cn (R) c1 ( c2 (…( cn ( R ))…))

2. Perubahan : Operasi dirubah menjadi : c1 ( c2 ( R ) ) c2 ( c1 ( R ) )

3. Pengurutan : Dalam sebuah urutan dari

operasi-operasi , semuanya, tetapi yang

terakhir dapat diabaikan : List1 ( List2 (…( Listn ( R ))…)) List1 ( R )

4. Merubah dengan : Jika kondisi pilihan c

hanya meliputi attribute-attribute A1,…,An

dalam daftar proyeksi, maka kedua operasi

dapat dirubah menjadi : A1,A2,…,An ( c ( R )) c ( A1,A2,…,An ( R ))

5. Perubahan dari ⋈ (dan x) : operasi ⋈ dirubah sebagaimana adanya operasi x :

R ⋈c S S ⋈c R

R x S S x R

Perlu diperhatikan bahwa meskipun urutan

dari attribute-attribute mungkin tidak sama

dalam relasi yang dihasilkan dari kedua join

(atau kedua cartesian product) tetapi artinya

adalah sama karena urutan dari attribute-

attribute tidaklah penting dalam definisi

pilihan dari relasi.

6. Merubah dengan ⋈ (atau x) : Jika semua

attribute-attribute dalam pilihan kondisi c

hanyalah meliputi attribute-attribute dari

satu relasi yang digabungkan (misalnya R),

maka kedua operasi-operasi tersebut dapat

dirubah seperti berikut ini :

c ( R ⋈ S ) ( c ( R )) ⋈ S

Sebagai alternatif, apabila pilihan kondisi c

dapat dituliskan sebagai (c1 dan c2), dimana

kondisi c1 hanya meliputi attribute-attribute

dari R dan kondisi c2 hanya meliputi

attribute-attribute dari S, maka operasi-

operasi dirubah seperti berikut :

c ( R ⋈ S ) ( c1 ( R )) ⋈ ( c2 ( S ))

Aturan yang sama dipakai apabila ⋈ digantikan oleh operasi x.


201

7. Merubah dengan ⋈ (atau x) : Anggap

bahwa daftar proyeksi adalah L = {A1,…,

An, B1,…, Bm} di mana A1,…, An adalah

attribute dari R dan B1,…, Bm adalah

attribute dari S. Apabila kondisi gabungan c

hanya meliputi attribute pada L, maka kedua

operasi dapat dirubah sebagai berikut :

L ( R ⋈c S ) (( A1,…,An, An+1,…,An+k ( R )) ⋈c ( B1,…,Bn,

Bn+1,…,Bn+k ( S )))

Untuk x, tidak ada kondisi c, jadi aturan

transformasi yang pertama adalah selalu

menggunakan penggantian ⋈c dengan x.

8. Perubahan sekumpulan operasi-operasi :

Kumpulan operasi dan adalah

perubahan, tetapi adalah bukan

perubahan.

9. Penggabungan ⋈, x, dan : Keempat

operasi ini adalah gabungan dari individu.

Maka dari itu, apabila berdiri untuk salah

satu dari keempat operasi tersebut

(sepanjang ekspresi) maka : ( R S ) T R ( S T )

10. Merubah dengan sekumpulan operasi-

operasi : operasi dirubah dengan , ,

dan . Apabila berdiri untuk salah satu

dari ketiga operasi tersebut (sepanjang

ekspresi), maka : c ( R S ) ( c ( R )) ( c ( S ))

11. Operasi dirubah dengan : L ( R S ) ( L ( R)) ( L ( S ))

12. Mengkonversikan sebuah urutan ( , x) ke

dalam ⋈ : Jika kondisi c dari sebuah

yang mengikuti sebuah x cocok untuk

sebuah kondisi join, maka urutan ( , x)

dikonversikan ke dalam sebuah ⋈ sebagai

berikut :

c ( R x S )) ( R ⋈c S ).

Untuk melakukan transformasi-

transformasi tersebut, query optimizer harus

mengetahui transformasi mana yang sah yaitu

yang menghasilkan sebuah hasil yang sama. Di

samping transformasi-transformasi yang sah,

sebuah optimizer juga harus mengetahui

bilamana aturan-aturan tersebut digunakan

untuk query. Setelah transformasi-transformasi

tersebut, optimizer menaruh kembali operasi-

operasi relasi pada query tree dengan operasi-

operasi fisik yang dapat dipakai untuk

membuat rencana eksekusi.

Garis besar dari algoritma optimisasi

aljabar heuristik adalah menggunakan beberapa

aturan-aturan transformasi relasi aljabar yang

telah dijelaskan sebelumnya untuk

mentransformasikan sebuah inisial query tree

(bentuk query tree yang belum dioptimisasi) ke

dalam sebuah tree yang optimal dan yang lebih

efisien untuk dijalankan. Adapun algoritma dari

optimisasi heuristik secara umum adalah :

Langkah 1 : Dengan menggunakan aturan

transformasi 1, pisahkan beberapa

operasi SELECT dengan kondisi-kondisi

konjungtif ke dalam uraian dari operasi-operasi

SELECT.


transformasi 2, 4, 6 dan 10 perhatikan

perubahan dari SELECT dengan operasi-

operasi lainnya, pindahkan tiap operasi

SELECT sejauh mungkin ke bawah query tree

selama diperbolehkan oleh attribute-attribute

yang rumit dalam kondisi SELECT.


tranformasi 5 dan 9, merubah dan

mengumpulkan operasi-operasi binary, susun

kembali node-node leaf dari tree menggunakan

kriteria-kriteria sebagai berikut. Pertama,

tempatkan relasi-relasi node leaf dengan

sebagian besar batasan operasi-operasi

SELECT sehingga relasi-relasi node leaf

dengan sebagian besar batasan operasi-operasi

SELECT dieksekusi terlebih dahulu ke dalam

representasi query tree. Definisi dari sebagian

besar batasan operasi SELECT salah satunya

dapat juga berarti yang menghasilkan sebuah

relasi dengan tuple-tuple yang paling sedikit

atau dengan ukuran yang mutlak.

Kemungkinan lainnya adalah untuk

menetapkan sebagian besar batasan SELECT

sebagai salah satunya dengan selectivity yang


202

terkecil. Hal ini adalah lebih praktis karena

perkiraan dari selectivity-selectivity biasanya

tersedia dalam katalog DBMS. Yang kedua,

pastikan bahwa urutan dari node-node leaf

tidak menyebabkan operasi-operasi

CARTESIAN PRODUCT. Sebagai contoh,

apabila dua relasi dengan sebagian besar

batasan SELECT tidak mempunyai kondisi join

secara langsung diantara keduanya, maka

diperlukan sekali untuk merubah urutan dari

node-node leaf untuk menghindari cartesian

product.

Langkah 4: Dengan menggunakan aturan

transformasi 12, kombinasikan operasi

CARTESIAN PRODUCT dengan sebuah

operasi SELECT yang berikutnya pada tree ke

dalam sebuah operasi JOIN, apabila kondisi

menggambarkan sebuah kondisi join.


transformasi 3, 4, 7, 11 perhatikan uraian dari

PROJECT dengan operasi-operasi lain,

pisahkan dan pindahkan daftar-daftar proyeksi

attribute-attribute ke bawah tree sejauh

mungkin dengan membentuk operasi-operasi

PROJECT yang baru sesuai dengan keperluan.

Hanya attribute-attribute itu yang diperlukan

dalam hasil query dan dalam operasi-operasi

berikutnya pada query tree harus disimpan

setelah masing-masing operasi PROJECT.

Langkah 6: Sebagai langkah terakhir,

identifikasikan subtree–subtree yang

menggambarkan kelompok-kelompok dari

operasi-operasi yang dapat dieksekusi dengan

menggunakan algoritma tunggal.

Cost Based Optimization

Query Optimizer tidak selalu tergantung

pada aturan-aturan heuristik. Query Optimizer

juga harus memperkirakan dan

membandingkan harga dari eksekusi sebuah

query menggunakan strategi-strategi eksekusi

yang berbeda dan harus memilih strategi

dengan perkiraan harga terendah. Untuk query-

query yang diterjemahkan, di mana

keseluruhan prosesnya terjadi pada saat

runtime, sebuah optimisasi dalam skala penuh

yang dapat memperlambat waktu respon.

Sebuah optimisasi yang lebih teliti ditunjuk

untuk menyusun query-query, sedangkan

sebagian, menghabiskan lebih sedikit waktu

optimisasi untuk menterjemahkan query-query.

Pendekatan ini disebut dengan cost

based query optimization. Dan cost based query

optimization menggunakan teknik-teknik

optimisasi yang tradisional yang mencari solusi

space untuk sebuah masalah, untuk sebuah

solusi yang meminimumkan fungsi-fungsi

obyektif (harga). Fungsi-fungsi harga yang

digunakan dalam optimisasi query adalah

perkiraan dan bukan fungsi-fungsi harga yang

tepat. Jadi optimisasi dapat memilih sebuah

strategi eksekusi query yang tidak optimal.

Komponen-komponen Harga untuk

Eksekusi Query

Komponen-komponen harga yang

digunakan untuk mengeksekusi query adalah:2

1. Access cost untuk secondary storage :

harga ini adalah harga untuk pencarian,

pembacaan dan penulisan blok-blok data

yang terletak pada secondary storage,

terutama pada disk. Harga dari pencarian

untuk record-record dalam sebuah file

tergantung pada tipe dari bentuk-bentuk

akses pada file tersebut, seperti pengurutan

(ordering), hashing dan pengindeks-an

primary ataupun secondary. Sebagai

tambahan, faktor-faktor seperti disediakan

atau tidaknya blok-blok file yang berdekatan

pada silinder disk yang sama atau tersebar

pada disk juga dapat mempengaruhi harga

akses.

2. Storage cost : Harga ini adalah harga dari

penyimpanan file-file menengah yang

dihasilkan oleh sebuah strategi eksekusi

untuk query.

3. Computation cost : Harga ini adalah harga

dari pelaksanaan operasi-operasi memory

pada buffer-buffer data selama eksekusi

query. Seperti operasi-operasi pencarian dan


203

pengurutan record, penggabungan record-

record untuk sebuah join dan melakukan

perhitungan-perhitungan pada nilai-nilai

field.

4. Memory usage cost : Harga adalah harga

mengenai jumlah dari buffer-buffer memory

yang diperlukan selama eksekusi query.

5. Communication cost : Harga ini adalah

harga dari pengiriman query dan hasilnya

dari tempat database atau terminal di mana

query berasal.

HASIL DAN PEMBAHASAN

Simple SQL Optimizer

Simple SQL Optimizer merupakan

sebuah program sederhana yang terdapat dalam

software database MySQL , yang digunakan

untuk mengoptimisasi perintah SELECT.

Fungsi dari SQL Optimizer dalam software

database MySQL tersebut adalah memproses

suatu query untuk mendapatkan informasi yang

diinginkan dari database yang ada dengan

waktu akses yang singkat dan penggunaan

tabel-tabel database dapat diminimumkan.

Gambar 1. Arsitektur Simple SQL Optimizer

Algoritma Simple SQL Optimizer pada

software database MySQL adalah sebagai

berikut :

1. Mengenali perintah-perintah SELECT,

tabel, query, kondisi, fungsi-fungsi,

argumen-argumen, operator-operator,

operand-operand, variabel, konstan dan

kolom-kolom dengan menggunakan parser

untuk semua perintah SQL.

2. Memasukkan semua yang telah dikenali

tersebut ke dalam query tree untuk diproses

lebih lanjut.

3. Optimisasi SELECT. Tentukan index dari

tabel yang diperlukan. Tabel diakses satu-

persatu dari urutan penulisan pada bagian

“FROM” dari “SELECT”.

Opt_Search_Plan ()

Analisa kondisi pencarian untuk

mengetahui apa yang telah diketahui

tentang kondisi kolom-kolom pada tabel

yang memenuhi pada setiap join.

a. Pilih index di mana tabel akan diakses.

Opt_Search_Plan_For_Table ()

b. Tentukan kondisi pencarian di mana

tabel dapat diperiksa.

Opt_Determine_And_Normalize_Tes

t_Conds ()

c. Klasifikasikan kolom pada tabel yang dapat

diakses tanpa mengcopynya dengan yang

harus dicopy ke dynamic memory.

Opt_Classify_Cols ()

d. Hitung informasi yang diperlukan untuk

mengakses clustered index record.

Opt_Clust_Access ()

e. Cek apakah plan telah mematuhi semua

klausa order-by agar tidak menimbulkan

error.

Opt_Check_Order_By ()

Segmen program 4.1 opt_search_plan (sel_node_t*sel_node) 1: void

2: opt_search_plan(sel_node_t* sel_node)

3: {

4: sym_node_t* table_node;

5: dict_table_t* table;

6: order_node_t* order_by;

SIMPLE SQL

OPTIMIZER RENCANA

EKSEKUSI

PARSE

TREE


204

7: ulint i;

8: sel_node->plans = mem_heap_alloc(pars_sym_tab_global->heap,

9: sel_node->n_tables *sizeof(plan_t));

10: table_node = sel_node->table_list;

11: if (sel_node->order_by == NULL) {

12: sel_node->asc = TRUE;

13: } else {

14: order_by = sel_node->order_by;

15:

16: sel_node->asc = order_by->asc;

17: }

18: for (i = 0; i < sel_node->n_tables; i++) {

19: table = table_node->table;

20: opt_search_plan_for_table(sel_node, i, table);

21: opt_determine_and_normalize_test_conds(sel_node, i);

22: table_node = que_node_get_next(table_node);

23: }

24: table_node = sel_node->table_list;


26: opt_classify_cols(sel_node, i);

27: opt_clust_access(sel_node, i);

28: table_node = que_node_get_next(table_node);

29: }

30: opt_check_order_by(sel_node);

31: #ifdef UNIV_SQL_DEBUG

32: opt_print_query_plan(sel_node);

33: #endif

34: }

Langkah pertama dari segmen program

4.1 adalah menganalisa kondisi pencarian

untuk menemukan kondisi-kondisi kolom pada

tabel yang memenuhi pada tiap-tiap tahapan

join (baris 11-17). Baris 18-22 dijalankan untuk

mencari best index dari setiap tabel dengan

cara mula-mula memilih index di mana tabel

akan diakses dengan perintah

opt_search_plan_for_table () pada baris 20

yang dapat dilihat pada segmen program 4.2.,

kemudian dilanjutkan dengan menentukan

kondisi pencarian di mana tabel dapat diperiksa

(baris 21) dengan menggunakan perintah

opt_determine_and_normalize_test_conds().

Setelah itu, perintah opt_classify_cols() pada

baris 26 dijalankan untuk mengklasifikasikan

kolom-kolom tabel yang dapat diakses tanpa

mengcopy-nya dengan yang harus dicopy ke

dalam dynamic memory. Langkah selanjutnya

adalah menghitung informasi yang diperlukan

untuk mengakses cluster index record, yang

dapat dilakukan dengan menjalankan perintah

opt_clust_access() pada baris 27. Kemudian

harus di-cek apakah plan telah mematuhi

semua klausa order-by agar tidak menimbulkan

error dengan menggunakan perintah

opt_check_order_by () pada baris 30.

Segmen program 4.2 opt_search_plan_for_table(sel_node_t* sel_node,

ulint i, dict_table_t* table) 35: static

36: void

37: opt_search_plan_for_table(

38: sel_node_t* sel_node,

39: ulint i,

40: dict_table_t* table)


205

41: {

42: plan_t* plan;

43: dict_index_t* index;

44: dict_index_t* best_index;

45: ulint n_fields;

46: ulint goodness;

47: ulint last_op;

48: ulint best_goodness;

49: ulint best_last_op;

50: ulint mix_id_pos;

51: que_node_t* index_plan[128];

52: que_node_t* best_index_plan[128];

53: plan = sel_node_get_nth_plan(sel_node, i);

54: plan->table = table;

55: plan->asc = sel_node->asc;

56: plan->pcur_is_open = FALSE;

57: plan->cursor_at_end = FALSE;

58: index = dict_table_get_first_index(table);

59: best_goodness = 0;

60: while (index) {

61: goodness = opt_calc_index_goodness(index, sel_node, i,

62: index_plan, &last_op);

63: if (goodness > best_goodness) {

64: best_index = index;

65: best_goodness = goodness;

66: n_fields = opt_calc_n_fields_from_goodness(goodness);

67: ut_memcpy(best_index_plan, index_plan,

68: n_fields * sizeof(void*));

69: best_last_op = last_op;

70: }

71: index = dict_table_get_next_index(index);

72: }

73: plan->index = best_index;

74: n_fields = opt_calc_n_fields_from_goodness(best_goodness);

75: if (n_fields == 0) {

76: plan->tuple = NULL;

77: plan->n_exact_match = 0;

78: } else {

79: plan->tuple = dtuple_create(pars_sym_tab_global->heap,

80: n_fields);

81: dict_index_copy_types(plan->tuple, plan->index, n_fields);

82: plan->tuple_exps = mem_heap_alloc(pars_sym_tab_global ->heap,


84: ut_memcpy(plan->tuple_exps, best_index_plan,


86: if (best_last_op == '=') {

87: plan->n_exact_match = n_fields;

88: } else {

89: plan->n_exact_match = n_fields - 1;

90: }

91: plan->mode = opt_op_to_search_mode(sel_node->asc,

92: best_last_op);

93: }

94: if ((best_index->type & DICT_CLUSTERED)

95: && (plan->n_exact_match >= dict_index_get_n_unique(best_index)))

96: {

97: plan->unique_search = TRUE;


206

98: } else {

99: plan->unique_search = FALSE;

100: }

101: if ((table->type != DICT_TABLE_ORDINARY)

102: && (best_index->type & DICT_CLUSTERED)) {

103: plan->mixed_index = TRUE;

104: mix_id_pos = table->mix_len;

105: if (mix_id_pos < n_fields {

106: plan->tuple_exps[mix_id_pos] =

107: sym_tab_add_str_lit(pars_sym_tab_global,

108: table->mix_id_buf,

109: table->mix_id_len);

110: }

111: } else {

112: plan->mixed_index = FALSE;

113: }

114: plan->old_vers_heap = NULL;

115: btr_pcur_init(&(plan->pcur));

116: btr_pcur_init(&(plan->clust_pcur));

117: }

Fungsi dari segmen program 4.2 adalah

mengoptimisasi perintah select dan

memutuskan index-index mana dari tabel yang

akan digunakan. Algoritma segmen program ini

secara keseluruhan adalah menghitung nilai

goodness untuk index menurut select node.

Nilai goodness ini adalah empat kali

dari nomor field pertama pada index di mana

nilainya telah diketahui pada query. Baris 24

dan 25 digunakan untuk mencari index dari

tabel yang pertama. Baris 27 dan 28 digunakan

untuk menghitung apakah index yang ada

merupakan index terbaik. Jika tidak, maka

jalankan baris 35 untuk mencari index

berikutnya. Setelah didapatkan index terbaik,

maka disusun menjadi record-record (tuple-

tuple) menurut index tersebut (baris 45 sampai

baris 55).

Segmen program 4.3 opt_determine_and_normalize_test_conds(sel_node_t* sel_node, ulint i) 118: static

119: void

120: opt_determine_and_normalize_test_conds(


122: ulint i)

123: {

124: plan_t* plan;


126: UT_LIST_INIT(plan->end_conds);

127: UT_LIST_INIT(plan->other_conds);

128: opt_find_test_conds(sel_node, i, sel_node->search_cond);

129: opt_normalize_cmp_conds(UT_LIST_GET_FIRST(plan->end_conds),

130: plan->table);

131: ut_a(UT_LIST_GET_LEN(plan->end_conds) >= plan->n_exact_match);

132: }

Segmen program 4.3 digunakan untuk

menemukan pencarian kondisi yang didapat

dan diperlukan untuk mengetes tabel yang ke-i

dalam sebuah join yang dapat diakses.

Pencarian tuple dapat mengeliminasi keperluan

untuk pengetes beberapa konjungsi.


207

Segmen program 4.4 opt_classify_cols(sel_node_t*sel_node,ulint i) 133: static

134: void

135: opt_classify_cols(


137: ulint i)

138: {

139: plan_t* plan;

140: que_node_t* exp;


142: plan->must_get_clust = FALSE;

143: UT_LIST_INIT(plan->columns);

144: exp = sel_node->select_list;

145: while (exp) {

146: opt_find_all_cols(TRUE, plan->index, &(plan->columns),plan,exp);

147: exp = que_node_get_next(exp);

148: }

149: opt_find_copy_cols(sel_node, i, sel_node->search_cond);

150: opt_find_all_cols(FALSE, plan->index, &(plan->columns), plan,

151: sel_node->search_cond);

152: }

Segmen program 4.4 digunakan untuk

mengklasifikasikan kolom-kolom tabel sesuai

dengan yang digunakan

Variabel input untuk segmen program ini

adalah select node dan tabel yang ke-i dalam

join.

Segmen program 4.5 opt_clust_access( sel_node_t*sel_node, ulint n) 153: static

154: void

155: opt_clust_access(


157: ulint n)

158: {

159: plan_t* plan;

160: dict_table_t* table;

161: dict_index_t* clust_index;

162: dict_index_t* index;

163: dfield_t* dfield;

164: mem_heap_t* heap;

165: ulint n_fields;

166: ulint col_no;

167: ulint pos;

168: ulint i;

169: plan = sel_node_get_nth_plan(sel_node, n);

170: index = plan->index;

171: plan->no_prefetch = FALSE;

172: if (index->type & DICT_CLUSTERED) {

173: plan->clust_map = NULL;

174: plan->clust_ref = NULL;

175: return;

176: }

177: table = index->table;

178: clust_index = dict_table_get_first_index(table);

179: n_fields = dict_index_get_n_unique(clust_index);

180: heap = pars_sym_tab_global->heap;


208

181: plan->clust_ref = dtuple_create(heap, n_fields);

182: dict_index_copy_types(plan->clust_ref, clust_index, n_fields);

183: plan->clust_map = mem_heap_alloc(heap, n_fields * sizeof(ulint));

184: for (i = 0; i < n_fields; i++) {

185: col_no = dict_index_get_nth_col_no(clust_index, i);

186: pos = dict_index_get_nth_col_pos(index, col_no);

187: *(plan->clust_map + i) = pos;

188: ut_ad((pos != ULINT_UNDEFINED)

189: || ((table->type == DICT_TABLE_CLUSTER_MEMBER)

190: && (i == table->mix_len)));

191: }

192: if (table->type == DICT_TABLE_CLUSTER_MEMBER) {

193: dfield = dtuple_get_nth_field(plan->clust_ref, table->mix_len);

194: dfield_set_data(dfield, mem_heap_alloc(heap, table->mix_id_len),


196: ut_memcpy(dfield_get_data(dfield), table->mix_id_buf,


198: }

199: }

Segmen program 4.5 berfungsi untuk

mengisikan informasi pada plan yang akan

dipakai untuk mengakses clustered index

record. Semua kolom harus sudah

diklasifikasikan untuk plan node. Variabel

input dari segmen program ini adalah select

node dan tabel yang ke-n dalam select.

Segmen program 4.6 opt_check_order_by(sel_node_t*sel_node) 200: static

201: void

202: opt_check_order_by(

203: sel_node_t* sel_node)

204: {

205: order_node_t* order_node;

206: dict_table_t* order_table;

207: ulint order_col_no;

208: plan_t* plan;

209: ulint i;

210: if (!sel_node->order_by) {

211: return;

212: }

213: order_node = sel_node->order_by;

214: order_col_no = order_node->column->col_no;

215: order_table = order_node->column->table;



218: if (i < sel_node->n_tables - 1) {

219: ut_a(dict_index_get_n_unique(plan->index)

220: <= plan->n_exact_match);

221: } else {

222: ut_a(plan->table == order_table);

223: ut_a((dict_index_get_n_unique(plan->index)

224: <= plan->n_exact_match)

225: || (dict_index_get_nth_col_no(plan->index,

226: plan->n_exact_match)

227: == order_col_no));

228: }


209

229: }

230: }

Segmen program 4.6 dijalankan apabila

ada statement order-by kolom tabel. Fungsi

program ini adalah memutuskan apabila

pengambilan baris harus dilakukan secara

descending dan juga mengecek bahwa

pemilihan query plan yang dihasilkan adalah

sebuah hasil yang memenuhi order-by. Baris 17

sampai dengan baris 28 akan dijalankan apabila

ada sebuah klausa order-by, field-field yang

tidak tepat atau tidak cocok dalam index yang

digunakan untuk tabel terakhir dalam daftar

tabel harus didefinisikan menjadi kolom dalam

klausa order-by, dan untuk semua tabel lainnya

yang seharusnya hanya didapat pada

kebanyakan baris tunggal.

KESIMPULAN

1. Untuk menghasilkan rencana akses yang

efisien dari sebuah query, maka diperlukan

teknik-teknik khusus yang digunakan untuk

mengolah query tersebut menjadi sebuah

query yang optimal. Terdapat 2 teknik dasar

yang umumnya dipakai untuk proses

optimisasi sebuah query. Yang pertama

adalah Heuristic Optimization yang

menggunakan aturan-aturan heuristik dan

yang kedua adalah Cost based Optimization

yang menggunakan perkiraan-perkiraan

harga tertentu.

2. Perbandingan antara heuristic optimization

dan cost based optimization adalah :

Heuristic optimization merupakan urutan

rencana-rencana dari query tunggal.

Masing-masing rencana adalah lebih

efisien dari rencana-rencana sebelumnya.

Cost based optimization akan

menghasilkan banyak rencana-rencana

query. Harga dari masing-masing rencana

adalah merupakan perkiraan, dengan

memilih yang paling efisien.

DAFTAR PUSTAKA

Booth, Joseph D., & Craig Yellick, 2002, MS-

SQL Optimizer A Developer’s Guide

Volume 1 & 2, DBMS Magazine’s

Foundation Series.

Computer Associates, 2005, Programming and

Utilities Guide for MS-SQL Optimizer,

Computer Associates International, Inc.

http://cisnet.baruch.cuny.edu/holowczak/classe

s/9440/queryprocessing/

Yannis E. Ioannidis, 2004, Query Optimization,

University of Wisconsin.

http://cisnet.baruch.cuny.edu/holowczak/classes/9440/queryprocessing/

http://cisnet.baruch.cuny.edu/holowczak/classes/9440/queryprocessing/

Documents

Jurnal Query