Pertanyaan Apakah urutan kolom dalam klausa WHERE penting?


Apakah urutan kolom dalam kinerja efek klausa WHERE?

misalnya

Katakanlah saya meletakkan kolom yang memiliki potensi lebih tinggi untuk keunikan pertama atau sebaliknya?


32
2018-03-13 13:46


asal


Jawaban:


Dengan pengoptimal kueri yang layak: seharusnya tidak.

Namun dalam prakteknya, saya menduga itu mungkin.

Anda hanya bisa mengatakan untuk kasus Anda dengan mengukur. Dan pengukuran kemungkinan akan berubah sebagai distribusi perubahan data dalam database.


15
2018-03-13 13:48



Untuk Transact-SQL ada preseden yang didefinisikan untuk operator di kondisi klausa WHERE. Pengoptimal dapat mengatur ulang evaluasi ini, jadi Anda tidak boleh bergantung pada perilaku hubungan arus pendek untuk kebenaran. Urutan umumnya kiri ke kanan, tetapi selektivitas / ketersediaan indeks mungkin juga penting. Menyederhanakan kondisi pencarian Anda harus meningkatkan kemampuan pengoptimal untuk mengatasinya.

Ex:

 WHERE (a OR b) AND (b OR c)

dapat disederhanakan menjadi

 WHERE b OR (a AND c)

Jelas dalam hal ini jika query dapat dibangun untuk menemukan apakah b memegang pertama mungkin dapat melewati evaluasi a dan c dan dengan demikian akan berjalan lebih cepat. Apakah pengoptimal dapat melakukan transformasi sederhana ini saya tidak dapat menjawab (mungkin bisa), tetapi intinya adalah bahwa itu mungkin tidak dapat melakukan transformasi yang semaunya rumit dan Anda mungkin dapat mempengaruhi kinerja query dengan menata ulang kondisi Anda. Jika b lebih selektif atau memiliki indeks, pengoptimal kemungkinan akan dapat membuat kueri yang menggunakannya terlebih dahulu.

EDIT: Berkaitan dengan pertanyaan Anda tentang pemesanan berdasarkan keunikan, saya akan menganggap bahwa petunjuk apa pun yang dapat Anda berikan kepada pengoptimal berdasarkan pengetahuan Anda (sebenarnya, tidak diasumsikan) dari data tidak ada salahnya. Berpura-pura bahwa itu tidak akan melakukan pengoptimalan apa pun dan membangun kueri Anda seolah-olah Anda perlu mendefinisikannya dari yang paling hingga yang paling tidak selektif, tetapi jangan terobsesi sampai kinerja benar-benar menjadi masalah.

Mengutip dari referensi di atas:

Urutan yang diutamakan untuk operator logika BUKAN (tertinggi),   diikuti oleh AND, diikuti oleh OR. Tanda kurung dapat digunakan untuk menggantikan   preseden ini dalam kondisi pencarian. Urutan evaluasi   operator logika dapat bervariasi tergantung pada pilihan yang dibuat oleh query   optimizer.


12
2018-03-13 14:15



Untuk SQL Server 2000/20005/2008, query optimizer biasanya akan memberi Anda hasil yang identik tidak peduli bagaimana Anda mengatur kolom dalam klausa WHERE. Setelah mengatakan ini, selama bertahun-tahun menulis ribuan perintah T-SQL, saya telah menemukan beberapa kasus di mana urutan mengubah kinerja. Berikut beberapa karakteristik kueri yang tampaknya tunduk pada masalah ini:

  1. Jika Anda memiliki sejumlah besar tabel dalam permintaan Anda (10 atau lebih).

  2. Jika Anda memiliki beberapa pernyataan EXISTS, IN, NOT EXISTS, or NOT IN dalam klausa WHERE Anda

  3. Jika Anda menggunakan bersarang CTE (ekspresi tabel biasa) atau sejumlah besar CTE.

  4. Jika Anda memiliki sejumlah besar sub-pertanyaan dalam klausa FROM Anda.

Berikut adalah beberapa kiat untuk mencoba mengevaluasi cara terbaik untuk menyelesaikan masalah kinerja dengan cepat:

  1. Jika masalah terkait dengan 1 atau 2, maka coba atur ulang klausa WHERE dan bandingkan biaya sub-pohon dari kueri dalam rencana kueri yang diperkirakan.

  2. Jika masalah terkait dengan 3 atau 4, cobalah memindahkan sub-kueri dan CTE keluar dari kueri dan minta mereka memuat tabel sementara. Pengoptimasi rencana kueri JAUH lebih efisien dalam memperkirakan rencana permintaan jika Anda mengurangi jumlah gabungan kompleks dan sub-kueri dari badan pernyataan T-SQL.

  3. Jika Anda menggunakan tabel sementara, maka pastikan Anda telah menentukan kunci utama untuk tabel sementara. Ini berarti hindari menggunakan SELECT INTO FROM untuk menghasilkan tabel. Sebaliknya, secara eksplisit buat tabel dan tentukan KUNCI primer sebelum menggunakan pernyataan INSERT INTO SELECT.

  4. Jika Anda menggunakan tabel sementara dan proses BANYAK pada server menggunakan tabel sementara juga, maka Anda mungkin ingin membuat tabel pementasan lebih permanen yang terpotong dan dimuat ulang selama proses kueri. Anda lebih mungkin mengalami masalah contention disk jika Anda menggunakan TempDB untuk menyimpan tabel kerja / pementasan Anda.

  5. Pindahkan pernyataan dalam klausa WHERE yang akan memfilter sebagian besar data ke awal klausa WHERE. Harap dicatat bahwa jika ini adalah solusi Anda untuk masalah ini, maka Anda mungkin akan memiliki kinerja yang buruk lagi di telepon ketika rencana permintaan menjadi bingung lagi tentang menghasilkan dan memilih rencana eksekusi terbaik. Anda TERBAIK mencari cara untuk mengurangi kompleksitas permintaan sehingga urutan klausa WHERE tidak lagi relevan.

Saya harap Anda menemukan informasi ini bermanfaat. Semoga berhasil!


7
2018-03-13 15:31



Itu semua tergantung pada DBMS, query optimizer dan aturan, tetapi umumnya itu mempengaruhi kinerja.

Jika klausa di mana memerintahkan sedemikian rupa sehingga kondisi pertama mengurangi resultet secara signifikan, kondisi yang tersisa hanya perlu dievaluasi untuk himpunan yang lebih kecil. Mengikuti logika itu, Anda dapat mengoptimalkan kueri berdasarkan pada urutan kondisi di mana klausa.


2
2018-03-13 13:55



Dalam teori setiap dua kueri yang setara harus menghasilkan rencana kueri yang identik. Sebagai urutan WHERE klausa tidak berpengaruh pada makna logis dari query, ini seharusnya berarti bahwa urutan WHERE klausa seharusnya tidak berpengaruh.

Ini karena cara pengoptimal kueri berfungsi. Di sebuah sangat disederhanakan ikhtisar:

  1. Pertama SQL Server mem-parsing query dan membangun pohon operator logis (misalnya JOIN atau SELECT).
  2. Kemudian menerjemahkan operator logis ini menjadi "pohon operasi physcial" (mis. "Nested Loops" atau "Pemindaian indeks", yaitu rencana eksekusi)
  3. Selanjutnya ia mengaktivasi melalui himpunan "pohon-pohon operasi fisik" yang setara (yaitu rencana pelaksanaan) dengan menukar operasi yang setara, memperkirakan biaya setiap rencana sampai menemukan yang optimal.

Langkah kedua yang dilakukan adalah cara sepenuhnya nieve - itu hanya memilih pohon fisik pertama / paling jelas yang bisa, namun pada langkah ke-3 pengoptimal kueri dapat melihat melalui semua pohon fisik ekuivalen (yaitu rencana pelaksanaan), dan selama pertanyaan sebenarnya setara, tidak masalah apa rencana awal yang kita dapatkan pada langkah 2, rangkaian rencana semua rencana yang dipertimbangkan pada langkah 3 adalah sama.

(Saya tidak dapat mengingat nama asli untuk pohon logis / fisik, mereka berada di sebuah buku tetapi sayangnya buku itu adalah sisi lain dari dunia saat ini)

Lihat seri artikel blog berikut untuk detail lebih lanjut Di dalam Pengoptimal: Membuat Rencana - Bagian 1

Pada kenyataannya Namun sering pengoptimal kueri tidak memiliki kesempatan untuk mempertimbangkan semua ekuivalen pohon di langkah 3 (untuk pertanyaan kompleks bisa ada sejumlah besar kemungkinan rencana), dan jadi setelah waktu cutoff tertentu langkah 3 dipotong pendek dan pengoptimal kueri harus memilih rencana terbaik yang telah ditemukan sejauh ini - di kasus ini tidak semua rencana akan dipertimbangkan.

Ada banyak di balik sihir sceene yang terus berlanjut untuk memastikan bahwa pengoptimal kueri secara selektif dan dengan cerdas memilih rencana untuk dipertimbangkan, dan sehingga sebagian besar waktu rencana choses adalah "cukup baik" - bahkan jika itu bukan rencana tercepat mutlak, itu mungkin tidak jauh lebih lambat daripada teori tercepat,

Namun apa artinya ini adalah bahwa jika kita memiliki rencana awal yang berbeda di langkah 2 (yang mungkin terjadi jika kita menulis permintaan kami secara berbeda), ini berpotensi berarti bahwa subset yang berbeda dari rencana dianggap pada langkah 3, dan sebagainya dalam teori SQL Server dapat muncul dengan rencana permintaan yang berbeda untuk kueri yang setara bergantung pada cara penulisannya.

Namun kenyataannya 99% dari waktu Anda tidak akan melihat perbedaannya (untuk banyak rencana sederhana di sana tidak akan terjadi menjadi perbedaan apa pun karena pengoptimal akan benar-benar mempertimbangkan semua rencana). Anda juga tidak dapat memprediksi bagaimana semua ini akan berhasil dan hal-hal yang mungkin terlihat masuk akal (seperti meletakkannya WHERE klausa dalam urutan tertentu), mungkin tidak memiliki efek yang diharapkan.


2
2018-04-11 11:38



Dalam Sebagian besar kasus pengoptimal kueri akan menentukan cara yang paling efisien untuk memilih data yang Anda minta, terlepas dari urutan SARGS yang ditentukan dalam klausa WHERE.

Urutan ditentukan oleh faktor-faktor seperti selektivitas kolom yang dipertanyakan (yang diketahui oleh SQL Server berdasarkan statistik) dan apakah indeks dapat digunakan atau tidak.


0
2018-03-13 15:07



Jika Anda ANDing ketentuan yang pertama tidak benar akan mengembalikan false, sehingga pesanan dapat mempengaruhi kinerja.


-4
2018-03-13 13:49