Di MySQL, apakah urutan kolom dalam klausa WHERE memengaruhi kinerja kueri?

Saya mengalami masalah kinerja pada permintaan basis data tertentu yang memiliki set hasil yang besar.

Kueri yang dimaksud, saya punya tiga ANDdalam klausa WHERE

Apakah urutan klausa itu penting?

Seperti pada, jika saya menempatkan klausa ASI_EVENT_TIME pertama (karena itu akan menghapus sebagian besar hasil dari salah satu klausa.

Apakah itu akan meningkatkan waktu berjalan pada kueri?

PERTANYAAN:

SELECT DISTINCT  activity_seismo_info.* 
FROM `activity_seismo_info` 
WHERE 
    activity_seismo_info.ASI_ACTIVITY_ID IS NOT NULL  AND 
    activity_seismo_info.ASI_SEISMO_ID IN (43,44,...,259) AND 
    (
        activity_seismo_info.ASI_EVENT_TIME>='2011-03-10 00:00:00' AND 
        activity_seismo_info.ASI_EVENT_TIME<='2011-03-17 23:59:59'
    ) 

ORDER BY activity_seismo_info.ASI_EVENT_TIME DESC

JELASKAN kueri:

+----+-------------+---------+-------+---------------------------+--------------+---------+------+-------+-----------------------------+ 
| id | select_type | table   | type  | possible_keys             | key          | key_len | ref  | rows  | Extra                       |
+----+-------------+---------+-------+---------------------------+--------------+---------+------+-------+-----------------------------+ 
|  1 | SIMPLE      | act...o | range | act...o_FI_1,act...o_FI_2 | act...o_FI_1 | 5       | NULL | 65412 | Using where; Using filesort |
+----+-------------+---------+-------+---------------------------+--------------+---------+------+-------+-----------------------------+

Menggunakan:

PHP 5.2

MySQL 5.0.51a-3ubuntu5.4

Propel 1.3

Symfony 1.2.5

Saya kira tidak. Pengoptimal kueri harus cukup pintar.

Anda dapat mencoba mengatur ulang klausa WHERE dan melihat bahwa EXPLAINS memberi tahu Anda hal yang sama dalam setiap kasus.

Tentang apa yang dapat dilakukan untuk mengoptimalkan kueri ini: Apakah ada indeks di ASI_EVENT_TIME? (ini yang paling penting menurut saya untuk kueri ini karena Anda juga mengurutkan hasil menggunakannya).

Apakah ada indeks pada dua bidang lainnya (ASI_SEISMO_ID dan ASI_ACTIVITY_ID)?

Akan sangat membantu jika Anda memposting struktur tabel.

Dari dokumentasi :

Jika tabel memiliki indeks multi-kolom, awalan paling kiri dari indeks dapat digunakan oleh pengoptimal untuk menemukan baris. Misalnya, jika Anda memiliki indeks tiga kolom di (col1, col2, col3), Anda telah mengindeks kemampuan pencarian di (col1), (col1, col2), dan (col1, col2, col3).

MySQL tidak dapat menggunakan indeks jika kolom tidak membentuk awalan paling kiri dari indeks.

Jadi ya, itu harus sama dengan urutan kolom dalam indeks gabungan .

Tidak, itu tidak masalah.

Pengoptimal melakukan banyak transformasi sederhana langsung setelah mem-parsing SQL - ini adalah salah satunya.

DI MANA foo DAN bar

mengoptimalkan sama dengan

DI MANA bar DAN foo

Namun,

WHERE tidak sama dengan # 1 DAN tidak sama dengan # 2

Tidak dapat mengoptimalkan kedua bagian. Sebagai contoh,

DI MANA ANTARA 1 dan 3 DAN b> 17

tidak dapat memanfaatkan INDEX (a, b) atau INDEX (b, a)

Untuk frasa berbeda, tes '=' apa pun DAN bersama-sama dalam klausa WHERE digunakan terlebih dahulu satu non - '=' (IN, ANTARA,>, dll) dapat ditangani. Tidak lebih dari satu dapat dioptimalkan secara efektif.

Kueri Anda memiliki 3 klausa seperti itu.

Ternyata, INDEX (EVENT_TIME) mungkin yang paling berguna - ini akan membantu dengan salah satu AND, dan mungkin digunakan untuk menghindari "filesort" untuk ORDER BY.

Jika tidak ada baris duplikat (mengapa ada?), Lalu singkirkan DISTINCT. Itu bahkan menyebabkan lebih banyak upaya.

Berikan SHOW CREATE TABLE dan SHOW TABLE STATUS saat mengajukan pertanyaan kinerja.

Perbarui ... Versi yang lebih baru (mis., MySQL 5.7) dapat, dalam beberapa situasi, memperlakukan IN( list of constants )hampir seperti =. Agar aman, patuhi pesanan ini (setiap bagian bersifat opsional):

1. Sejumlah =.
2. Beberapa INs.
3. Paling banyak satu rentang.

MySQL di mana dokumen pengoptimalan mengatakan:

Anda mungkin tergoda untuk menulis ulang pertanyaan Anda untuk membuat operasi aritmatika lebih cepat, sambil mengorbankan keterbacaan. Karena MySQL melakukan optimasi serupa secara otomatis , Anda sering dapat menghindari pekerjaan ini, dan meninggalkan kueri dalam bentuk yang lebih mudah dipahami dan dipelihara. Beberapa optimasi yang dilakukan oleh MySQL mengikuti:

• ...

• Untuk setiap tabel dalam suatu join, WHERE yang lebih sederhana dibuat untuk mendapatkan evaluasi WHERE yang cepat untuk tabel tersebut dan juga untuk melewati baris sesegera mungkin .

• Setiap indeks tabel dipertanyakan, dan indeks terbaik digunakan kecuali pengoptimal percaya bahwa lebih efisien menggunakan pemindaian tabel . Pada suatu waktu, pemindaian digunakan berdasarkan apakah indeks terbaik membentang lebih dari 30% dari tabel, tetapi persentase tetap tidak lagi menentukan pilihan antara menggunakan indeks atau pemindaian. Pengoptimal sekarang lebih kompleks dan mendasarkan perkiraannya pada faktor-faktor tambahan seperti ukuran tabel, jumlah baris, dan ukuran blok I / O.

Dengan cara ini rasional untuk pengoptimal kueri untuk menghilangkan BAGAIMANA kita menggunakan kolom dalam kueri (Tidak hanya MySQL tetapi SQL adalah bahasa deklaratif dan harus melakukan apa yang kita inginkan bukan seperti yang kita inginkan).

Namun saya masih suka memiliki jenis yang sama untuk kolom kunci komposit dalam permintaan tetapi kadang-kadang tak terhindarkan misalnya ketika kita menggunakan ORM atau ActiveRecord, dalam beberapa kerangka kerja seperti yii2, menyesuaikan kriteria relasi akan ditambahkan pada akhir kondisi "aktif" tetapi kita masih membutuhkan kemampuan QueryBuilders di berbagai bagian aplikasi.

Setiap bidang yang digunakan dalam klausa WHERE / HAVING Anda dan memiliki selektivitas tinggi (jumlah nilai unik / jumlah total catatan> 10% ~ 20%) HARUS diindeks.

Jadi, jika ASI_EVENT_TIMEkolom Anda memiliki banyak nilai yang mungkin, pertama-tama indeks semuanya. Kemudian seperti yang dikatakan @ypercube, coba atur ulang dan lihat apa yang EXPLAIN katakan. Seharusnya semuanya hampir sama.

Selain itu, ingin Anda melihat pada Indexing SQL LIKE Filter . Meskipun itu bukan jawaban yang Anda butuhkan, tetapi Anda masih akan belajar tentang bagaimana pengindeksan bekerja di bawah tenda.

* Sunting: Lihat tautan yang disediakan di bawah di komentar untuk mempelajari lebih lanjut tentang pengindeksan.