Ringkaskan operasi paling asas pengoptimuman MySQL

                                                                                                               

Idea pengoptimuman

Langkah pengoptimuman MySQL terperinci adalah seperti berikut:

• Periksa struktur jadual data dan perbaiki reka bentuk yang tidak sempurna
• Jalankan perniagaan utama dan kumpulkan SQL pertanyaan pangkalan data yang biasa digunakan
• Analisis SQL pertanyaan, bahagikannya dengan sewajarnya, tambah indeks, dsb. untuk mengoptimumkan pertanyaan
• Semasa mengoptimumkan SQL, mengoptimumkan logik kod
• Tambah cache setempat dan cache redis

Jangan gunakan nilai NULL ​​jika boleh

Kerana semasa membuat jadual, jika anda tidak menetapkan nilai lalai untuk nilai yang dicipta, MySQL Tetapan lalai ialah NULL. Jadi mengapa tidak baik untuk menggunakan NULL?

• NULL menjadikan penyelenggaraan indeks lebih rumit adalah amat disyorkan untuk menetapkan pertanyaan bersyarat negatif seperti NOT NULL
• NOT IN dan != pada lajur indeks apabila. terdapat NULL Dalam kes nilai, hasilnya sentiasa kosong dan pertanyaan adalah terdedah kepada ralat Lajur
• NULL memerlukan bait tambahan sebagai bendera untuk menentukan sama ada ia adalah <.>. NULL
Apabila menggunakan
• dan Nilai lain dalam lajur mungkin bukan jenis yang sama, menyebabkan masalah. (Berprestasi berbeza dalam bahasa yang berbeza) NULL
MySQL mengalami kesukaran mengoptimumkan pertanyaan untuk lajur yang boleh
• NULL

Jadi untuk medan yang malas sebelum ini, tetapkan Nilai lalai secara manual, rentetan kosong, isikan dengan 0.

Walaupun kaedah ini tidak banyak meningkatkan prestasi MySQL, ia adalah tabiat yang baik, dan adalah penting untuk tidak mengabaikan butiran ini.

Tambah indeks

Untuk medan yang kerap ditanya, sila tambah indeks Kelajuan pertanyaan dengan dan tanpa indeks berbeza sebanyak sepuluh kali atau lebih.

Secara umumnya, setiap jadual perlu mempunyai kunci utama
• medan id
Medan yang biasa digunakan untuk pertanyaan hendaklah diindeks
• taip Medan, apabila membina indeks, sebaiknya tentukan panjang varchar
Apabila pertanyaan mempunyai berbilang syarat, syarat dengan indeks lebih disukai
• Carian kabur seperti
• syarat untuk indeks medan adalah Tidak sah, indeks kata kunci lain perlu diwujudkan untuk menyelesaikannya LIKE
• Sila cuba untuk tidak mengekang hubungan antara jadual dan jadual di peringkat pangkalan data Kebergantungan antara jadual ini harus diselesaikan pada peringkat kod

Apabila terdapat kekangan antara jadual, walaupun pernyataan SQL untuk penambahan, pemadaman dan pertanyaan menjadi lebih mudah, kesan negatifnya ialah pangkalan data akan menyemak kekangan untuk operasi seperti sisipan (walaupun ia boleh ditetapkan secara manual untuk mengabaikan Kekangan), yang setara dengan menulis beberapa logik perniagaan ke lapisan pangkalan data, yang menyusahkan untuk dikekalkan.

Optimumkan struktur medan jadual

Jangan gunakan jenis rentetan untuk data dalam pangkalan data yang boleh diwakili oleh integer sama ada hendak menggunakan

atau varchar bergantung pada Nilai yang mungkin untuk medan. char

Pengoptimuman jenis ini selalunya tidak dapat dilaksanakan apabila terdapat sejumlah besar data dalam pangkalan data Adalah lebih baik untuk mereka bentuknya sebelum reka bentuk pangkalan data.

Untuk lajur dengan kemungkinan nilai yang sangat terhad, gunakan
• dan bukannya tinyint, VARCHAR
  Contohnya, untuk merakam platform peranti mudah alih, hanya terdapat dua nilai: android , ios, kemudian Anda boleh menggunakan 0 untuk mewakili android dan 1 untuk mewakili ios Jenis lajur ini mesti diulas
  • Mengapa tidak menggunakan
  • ? ENUM sukar untuk dikembangkan Contohnya, platform mudah alih kemudiannya menambahkan ENUM, yang akan mengelirukan, tetapi menambah 2 kepada ipad sudah memadai dan tinyint sangat pelik untuk dikendalikan dalam kod. , kerana ia dianggap sebagai pembedahan plastik Atau rentetan, setiap bahasa adalah berbeza. ENUM
  Dengan cara ini, makna setiap nilai mesti ditulis dalam komen atau kod pangkalan data
Untuk rentetan panjang tetap tersebut, anda boleh menggunakan
• , seperti Poskod, sentiasa 5 digit char
Untuk rentetan yang tidak diketahui panjangnya, gunakan
• varchar
Jangan salah guna
• , seperti jadual bigint medan yang merekodkan nombor daripada artikel, gunakan idItu sahaja, had atas 2.1 bilion artikel sudah memadaiint
Pecahkan paradigma pangkalan data dengan sewajarnya dan tambah medan berlebihan untuk mengelakkan sambungan jadual semasa pertanyaan

Apabila bertanya, pastikan anda menggunakan jenis

Ia lebih pantas daripada int, kerana perbandingan integer boleh dicapai dengan memanggil terus operator pendasar, manakala perbandingan rentetan perlu dibandingkan dengan aksara demi aksara. varchar

Pertanyaan data panjang tetap adalah lebih pantas daripada pertanyaan data panjang berubah, kerana pengimbangan antara data panjang tetap dan data ditetapkan dan mudah untuk mengira pengimbangan data seterusnya. Untuk data panjang berubah-ubah, satu langkah lagi diperlukan untuk menanyakan offset data seterusnya. tetapi. Data panjang tetap mungkin membazir lebih banyak ruang storan.

Pisah jadual besar

Bagi jadual yang volum datanya mungkin melebihi 5 juta dalam masa terdekat atau berkembang pesat, pastikan anda melakukan pemisahan jadual menegak atau mendatar terlebih dahulu data Selepas volum melebihi satu juta, kelajuan pertanyaan akan menurun dengan ketara.

Cuba untuk memuktamadkan pelan untuk sub-pangkalan data dan sub-jadual pada peringkat awal reka bentuk pangkalan data, jika tidak, ia akan meningkatkan kerumitan kod dengan ketara dan sukar untuk diubah kemudian.

Pembahagian jadual menegak adalah berdasarkan pembolehubah luaran seperti tarikh, dan pembahagian jadual mendatar adalah berdasarkan perhubungan medan tertentu dalam jadual, menggunakan pemetaan cincang untuk membahagikan jadual kepada bahagian yang sama.

Prasyarat untuk sub-pangkalan data dan sub-pangkalan data jadual ialah sebelum melaksanakan pernyataan pertanyaan, anda sudah mengetahui sub-pangkalan data dan sub-jadual yang mana data yang hendak disoal mungkin termasuk.

Mengoptimumkan pernyataan pertanyaan

Ini adalah pemula kepada banyak kesesakan pangkalan data sistem.

• Sila cuba gunakan pertanyaan mudah dan elakkan menggunakan pautan jadual
• Sila cuba elakkan imbasan jadual penuh Pernyataan yang akan menyebabkan imbasan jadual penuh termasuk tetapi tidak terhad kepada:
  • Keadaan klausa di mana sentiasa benar atau kosong
  • Gunakan LIKE
  • Gunakan operator ketaksamaan (<>, !=)
  • Pertanyaan mengandungi is null Apabila menggunakan lajur
  • pada lajur bukan indeks or
• apabila membuat pertanyaan dengan berbilang syarat, sila letakkan syarat pertanyaan mudah atau pertanyaan lajur indeks di hadapan
• Sila cuba nyatakan lajur yang perlu ditanya, jangan malas menggunakan pilih *
  • Jika anda tidak nyatakan, di satu pihak, data berlebihan akan dikembalikan, menduduki lebar jalur , dsb.
  • Sebaliknya, MySQL melaksanakan pertanyaan Apabila tiada medan, ia akan menanyai medan dalam struktur jadual dahulu
• Kata kunci pertanyaan huruf besar ialah lebih pantas sedikit daripada huruf kecil
• Menggunakan subkueri akan membuat jadual sementara akan menjadi lebih perlahan daripada JOIN dan UNION
• Cuba untuk tidak menggunakan fungsi pangkalan data apabila membuat pertanyaan pada medan indeks, kerana ia menyusahkan. untuk cache hasil pertanyaan
• Apabila anda hanya memerlukan satu baris data, sila gunakan LIMIT 1. Jika terdapat terlalu banyak data, sila tetapkan LIMIT dengan sewajarnya Untuk pertanyaan paging
• jangan sekali-kali ORDER BY RAND(. ), prestasinya sangat rendah

Tambah cache

Menggunakan cache seperti redis dan cache fail setempat boleh mengurangkan bilangan pertanyaan pangkalan data. Apabila bercakap tentang caching, anda mesti menganalisis ciri data sistem anda sendiri dan membuat pilihan yang sesuai.

• Untuk beberapa data yang biasa digunakan, seperti maklumat konfigurasi, dsb., ia boleh diletakkan dalam cache
• Struktur jadual pangkalan data boleh dicache secara setempat
• Data cache mesti Beri perhatian kepada kemas kini tepat pada masanya dan tetapkan tempoh sah
• Meningkatkan cache pasti akan meningkatkan kerumitan sistem Pastikan anda memberi perhatian kepada pertukaran

Semak struktur jadual data

Pembelajaran yang disyorkan: "tutorial video mysql"

Atas ialah kandungan terperinci Ringkaskan operasi paling asas pengoptimuman MySQL. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!