Pengarang melaksanakan penyataan pertanyaan Pilih yang mudah dalam pangkalan data untuk mendapatkan semua maklumat dalam jadual, seperti yang ditunjukkan dalam rajah di bawah. Kini pentadbir pangkalan data ingin mengetahui kerja yang dilakukan oleh pangkalan data semasa melaksanakan pernyataan ini, atau sama ada terdapat sebarang kemungkinan pengoptimuman lanjut bagi pernyataan pertanyaan ini. Jika anda ingin mengetahui maklumat ini, anda boleh menambah kata kunci Terangkan pada pernyataan pertanyaan.
Data dalam jadual boleh disoal daripada pangkalan data melalui penyata pertanyaan Pilih. Kecekapan pelaksanaan dan ruang untuk pengoptimuman tidak boleh diperoleh daripada pernyataan pertanyaan mudah ini. Untuk memahami maklumat yang lebih terperinci, anda perlu menambah kata kunci Terangkan. Seperti yang ditunjukkan dalam rajah di bawah:
Selepas menambah kata kunci Terangkan, sistem tidak menanyakan data dalam jadual, tetapi hanya memaparkan beberapa maklumat semasa proses pertanyaan. Maklumat ini sangat membantu untuk pengoptimuman pertanyaan pangkalan data kami yang seterusnya. Daripada maklumat di atas, kita dapat melihat bahawa pengguna hanya membuat pertanyaan mudah. Dalam pertanyaan ini, tiada indeks, kata kunci atau penyataan Di mana digunakan. Atas sebab ini, pernyataan pertanyaan ini tidak begitu munasabah. Walaupun ia boleh menemui hasil akhir yang betul, kecekapan pertanyaannya mungkin tidak begitu jelas. Untuk tujuan ini pakar pangkalan data boleh melakukan pengoptimuman berdasarkan maklumat yang ditunjukkan di atas. Apakah hasilnya jika kami menambah pernyataan WHERE pada pertanyaan kami sekarang, seperti yang ditunjukkan dalam imej berikut?.
Apabila pernyataan Where digunakan dalam medan Tambahan yang terakhir, sistem akan menunjukkan bahawa ia telah digunakan. Semasa pengoptimuman pangkalan data, kita perlu menangkap medan atau medan NULL dengan kandungan kosong dalam hasilnya. Tempat-tempat ini selalunya menjadi tumpuan pengoptimuman kami. Anda boleh mengoptimumkan penyataan Pilih ini dan meningkatkan kecekapan pertanyaan dengan menetapkan kata kunci atau indeks dalam jadual, seperti yang ditunjukkan dalam rajah.
Apabila menanyakan data, kadangkala syarat penghakiman ditambahkan pada pernyataan bersyarat. Kini terdapat dua jadual: jadual maklumat asas pengguna dan jadual kebenaran pengguna, yang berkaitan dengan nombor pengguna. Untuk menanyakan maklumat kebenaran setiap pengguna, anda perlu menggunakan nombor pengguna sebagai syarat pertanyaan. Sekarang andaikan bahawa medan nombor pengguna dalam jadual maklumat asas pengguna adalah jenis CHAR dan medan nombor pengguna dalam jadual kebenaran pengguna adalah jenis VARCHAR. Walaupun kedua-dua jenis data ini adalah kedua-dua jenis aksara, ia bukan jenis yang sama. Sekarang laksanakan pertanyaan korelasi pada kedua-dua jadual ini Sejauh manakah pertanyaan itu yang perlu ditentukan ialah walaupun ia adalah jenis data aksara, ia serasi antara satu sama lain. Anda masih boleh mendapatkan hasil yang betul pada akhirnya. Selepas menjelaskan perkara ini, mari kita pertimbangkan sama ada pernyataan pertanyaan ini boleh dioptimumkan
Mari kita buat hipotesis lain. Sekarang jenis data nombor pengguna dalam kedua-dua jadual ialah CHAR. Sekarang lakukan pertanyaan berkaitan pada kedua-dua jadual ini Adakah keputusan yang diperolehi adalah sama. Hasil ujian kami ialah keputusan pertanyaan adalah sama, tetapi masa yang dibelanjakan adalah berbeza. Dan apabila jumlah data meningkat, perbezaan masa antara dua pertanyaan akan menjadi lebih lama dan lebih lama. Dari sini kita boleh tahu bahawa walaupun kedua-dua pernyataan pertanyaan adalah setara, kecekapan pertanyaan mereka adalah berbeza.
Walaupun jenis data serasi antara satu sama lain dalam pangkalan data MySQL, perbandingan masih boleh dibuat. Walau bagaimanapun, kecekapan pertanyaannya akan terjejas. Untuk meningkatkan kecekapan pertanyaan pangkalan data, penulis mengesyorkan agar lebih baik membandingkan lajur jenis yang sama dalam pernyataan syarat pertanyaan. Di bawah keadaan yang sama, jenis lajur yang sama boleh memberikan prestasi yang lebih baik daripada lajur pelbagai jenis. Ini amat penting dalam pangkalan data dengan jumlah data yang besar.
Walau bagaimanapun, pengoptimuman ini perlu melibatkan jenis lajur jadual data. Atas sebab ini, anda perlu mempertimbangkan perkara ini semasa mereka bentuk jadual data. Untuk kes di atas, kami boleh menambah lajur ID pengguna secara khusus pada kedua-dua jadual ini. Anda boleh menggunakan urutan jenis integer untuk membenarkan sistem menomborkan secara automatik. Kemudian bandingkan melalui lajur ID pengguna ini apabila membuat pertanyaan, bukannya membandingkan melalui lajur nombor pengguna asal. Secara relatifnya, kecekapan operasi pertanyaan akan lebih tinggi.
Dalam kerja sebenar, penulis mendapati ramai pentadbir pangkalan data mempunyai tabiat buruk. Apabila mereka menggunakan kata kunci seperti Suka, mereka menggunakan kad bebas secara rawak. Sebagai contoh, kini pengguna perlu mencari semua maklumat produk yang diawali dengan "LIHAT". Apabila membuat pertanyaan, pengguna biasanya terbiasa menggunakan pernyataan yang serupa dengan yang berikut: gunakan seperti "%LOOK%". Pernyataan bersyarat ini akan memperoleh semua rekod yang mengandungi perkataan LOOK dalam nama produk, bukannya hanya mendapatkan maklumat produk yang diawali dengan LOOK.
Walaupun hasil akhirnya mungkin sama. Walau bagaimanapun, kecekapan pertanyaan kedua-duanya adalah berbeza. Malah, sebahagian besar daripada ini disebabkan oleh reka bentuk aplikasi pelanggan yang tidak betul. Sebagai contoh, apabila mereka bentuk aplikasi klien, sistem akan memaparkan simbol % secara lalai. Seperti yang ditunjukkan di bawah.
Niat reka bentuk ini adalah baik, supaya sistem boleh menyokong pertanyaan kabur. Tetapi pengguna mungkin menghadapi masalah dalam operasi sebenar. Jika pengguna tidak memasukkan perkataan LOOK sebelum % semasa membuat pertanyaan, tetapi memasukkan perkataan selepas %. Kerana apabila membuat pertanyaan, kursor secara automatik akan diletakkan di belakang tanda %. Biasanya, pengguna tidak melaraskan kedudukan kursor semasa menaip. Pada masa ini, situasi yang dinyatakan di atas berlaku.
Untuk mengelakkan situasi yang tidak dijangka, penulis amat mengesyorkan agar anda berhati-hati apabila menggunakan kata kunci seperti Suka diikuti dengan kad bebas. Terutama apabila mencari rekod daripada sejumlah besar data, kedudukan kad bebas ini mesti digunakan di tempat yang betul. Jika anda boleh menggunakan kad bebas yang berbeza pada mulanya, cuba jangan gunakan kad bebas.
Seperti yang dinyatakan di atas, anda perlu memberi perhatian kepada kedudukan kad bebas apabila menggunakan kata kunci Suka. Dari segi kecekapan pertanyaan, kita perlu memberi perhatian kepada kedudukan kad bebas dan elakkan menggunakan kata kunci "Suka" sebanyak mungkin. Malah, dalam pernyataan SQL, kaedah lain boleh digunakan untuk menggantikan kata kunci Suka. Sebagai contoh, terdapat jadual produk dengan nombor 6 digit. Sekarang kita perlu menanyakan nombor produk bermula dengan 9. Bagaimana untuk melakukannya?
Mula-mula, anda boleh menggunakan kata kunci Suka, seperti SUKA "9%". Perhatikan kedudukan kad bebas ini. Pernyataan bersyarat ini boleh mendapatkan hasil yang diperlukan. Tetapi dari perspektif pengoptimuman prestasi, kenyataan ini bukanlah cara yang baik untuk mengendalikannya. Kita juga boleh mencapai ini melalui beberapa kompromi.
Yang kedua dicapai dengan membandingkan simbol. Ayat ini boleh dirumuskan semula sebagai: Ini boleh dicapai dengan menggunakan kaedah dengan Nilai antara 900000 dan 999999. Walaupun keputusan kedua-dua pertanyaan adalah sama. Walau bagaimanapun, masa pertanyaan pernyataan ini adalah lebih pendek daripada pernyataan di atas menggunakan simbol Suka.
Atas ialah kandungan terperinci Apakah kaedah untuk meningkatkan kecekapan pertanyaan MySQL dan pengoptimuman kelajuan pertanyaan?. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!
![[Web front-end] Permulaan pantas Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
