Jangan panik apabila sesuatu berlaku, rekodkannya dahulu: mysql dalam pengoptimuman pertanyaan perlahan

Artikel ini membawakan kepada anda masalah pengoptimuman pertanyaan mysql yang perlahan. Saya akan membawa anda langkah demi langkah untuk menganalisis SQL, menyemak dan mengoptimumkan.

Ingat pengoptimuman pertanyaan lambat mysql - demonstrasi langsung senarai tugasan persekitaran pengeluaran mengambil masa 5~6 saat untuk memuatkan keputusan ; tiba-tiba, produk Pengurus itu tidak tahan lagi Sebagai pemaju senior yang berpengalaman bertahun-tahun, dia memikirkannya, dan wajahnya dipenuhi dengan ketawa.

Namun, dengan pengalaman bertahun-tahun dalam arena, jangan panik apabila sesuatu berlaku dan ambil gambar dahulu.

Pembelajaran yang disyorkan: "Tutorial Video MySQL"

Langkah pertama, analisis SQL

 ***from event i 
 left join project p on i.project_id = p.project_code 
 left join dict d on i.type_id = d.id 
 left join record re on re.incident_id = i.id
 left join type it on it.id = i.type_id 
 where i.version_flag = 0 and i.flow_id in (大量条件)***复制代码

Apabila flow_id masuk Apabila sebilangan besar syarat disambungkan, SQL terus menjadi perlahan, daripada 80ms sebelumnya kepada 5.8 saat Selain itu, terdapat banyak jadual yang berkaitan di sini.

Langkah kedua ialah menyemak indeks dan laksanakan explain

Apabila kita menyemak indeks dan mendapati re.incident_id dan i.flow_id tidak diindeks, jadi, kegembiraan yang besar, masalah ditemui , membina indeks bagaimanapun, apabila melaksanakan SQL, didapati bahawa tidak ada telur! Sepandai-pandai saya, saya membuka explain terus dan mendapati jenis rekod adalah semua, bermakna tiada indeks.

mengapa?mengapa?

Langkah ketiga ialah menyemak sama ada jenis medan, panjang dan jenis aksara bagi dua medan yang berkaitan adalah konsisten

Apabila membandingkan medan Jenis dan panjang medan didapati betul-betul sama Selepas tempoh kemurungan yang singkat, saya menemui petunjuk baharu -

Jenis watak id jadual acara ialah:

Jenis watak incident_id dalam jadual rekod ialah:

Menggunakan utf8mb4 secara tegas dan seragam untuk mengekalkan perpaduan dengan pasukan projek ; terangkan sekali lagi, dan masa adalah serendah 1 saat, secara manual.

Langkah keempat ialah memaksa penggunaan operasi indeks

mysql akan melakukan carian teks penuh secara lalai dalam jadual seperti jika pangkalan indeks terlalu kecil , jadi jika volum perniagaan jadual terlalu besar, tetapi medan indeks pada asasnya adalah data yang sama atau nol, indeks paksaan masih perlu ditulis dalam penggunaan SQL ; penyelesaian indeks paksa dalam SQL untuk menambah daya selepas kiri join index(alarm_id)——

Langkah kelima, IN biasanya diindeks

Hanya apabila data selepas IN berada dalam Apabila memadankan lebih daripada 30% dalam jadual data, keseluruhan jadual diimbas tanpa menggunakan indeks Oleh itu, sama ada IN menggunakan indeks atau tidak adalah berkaitan jumlah data seterusnya. Sebilangan besar data boleh diproses menggunakan gabungan kiri.

Atas ialah kandungan terperinci Jangan panik apabila sesuatu berlaku, rekodkannya dahulu: mysql dalam pengoptimuman pertanyaan perlahan. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!