Analisis pelan indeks ringkas MySQL

Mysql simple index

1. Cara mencari apabila tiada indeks

Abaikan konsep indeks dahulu, jika anda ingin menyemak rekod tertentu secara langsung sekarang, bagaimana untuk mencarinya?

Cari dalam satu halaman

Jika terdapat sangat sedikit rekod dalam jadual dan satu halaman sudah mencukupi, maka terdapat dua situasi:

• Gunakan kunci utama sebagai syarat carian: Ini ialah kaedah yang disebutkan dalam artikel sebelumnya Gunakan kaedah dikotomi untuk mencari slot dengan cepat dalam direktori halaman, kemudian merentasi rekod yang sepadan dengan kumpulan slot, dan akhirnya mencari rekod yang ditentukan. .

• Gunakan lajur bukan kunci utama lain sebagai syarat carian: Oleh kerana tiada direktori halaman untuk lajur bukan kunci utama dalam halaman data, slot tidak boleh didapati dengan cepat melalui kaedah dikotomi dan hanya boleh dimulakan daripada rekod Infimum apabila Melintasi setiap rekod dalam senarai pautan tunggal adalah tidak cekap.

Cari dalam banyak halaman

Apabila terdapat banyak rekod dalam jadual, banyak halaman data akan digunakan untuk menyimpannya Dalam kes ini, 2 langkah diperlukan:

• Cari halaman tempat rekod berada.

• Ulang proses carian di atas dalam halaman.

Secara amnya, apabila tiada indeks, kami tidak dapat mengesan halaman dengan cepat di mana rekod terletak Kami hanya boleh mengikuti senarai terpaut dua kali dari halaman pertama (halaman mempunyai halaman sebelumnya dan halaman seterusnya) Teruskan mencari, dan kemudian ulangi proses di atas pada setiap halaman untuk menanyakan rekod yang ditentukan, yang memerlukan merentasi semua rekod, yang sangat memakan masa.

2. Indeks ringkas

Memandangkan rekod kedudukan terlalu perlahan kerana terlalu banyak halaman, bagaimana untuk menyelesaikannya? Anda mungkin ingin merujuk kepada "Direktori Halaman".

Direktori halaman disediakan untuk mengesan kedudukan rekod dalam halaman dengan cepat berdasarkan kunci utama. Oleh itu, kita boleh meneroka kaedah mencipta "direktori lain" untuk mencari halaman dengan cepat di mana rekod itu berada.

Tetapi ada dua perkara yang perlu dilakukan sebelum "direktori lain" ini dapat disiapkan.

1. Nilai kunci utama rekod pengguna pada halaman seterusnya mestilah lebih besar daripada halaman sebelumnya

Dengan mengandaikan bahawa setiap halaman data boleh menyimpan sehingga 3 rekod (sebenarnya banyak yang boleh diletakkan), kemudian Sekarang masukkan 3 rekod ke dalam jadual, setiap rekod mempunyai 3 lajur c1, c2, dan c3. Untuk kemudahan, format baris storan juga dipermudahkan, hanya meninggalkan atribut utama. Rekod maya Infimum dan Supremum masing-masing terletak pada permulaan dan akhir rekod pengguna, dengan tiga rekod pengguna di tengah.

Pada masa ini, teruskan memasukkan 1 rekod. Dalam kes hipotetikal, sekurang-kurangnya satu halaman baharu perlu diperuntukkan, jadi dua halaman itu akan diperuntukkan semula dan disusun semula.

Sila ambil perhatian bahawa dua rekod yang ditunjukkan dalam fon merah termasuk rekod yang baru dimasukkan dengan kunci utama 4, yang harus diletakkan pada halaman baharu. Walau bagaimanapun, untuk memenuhi keperluan bahawa nilai kunci utama rekod pengguna pada halaman seterusnya mestilah lebih besar daripada nilai kunci utama rekod pengguna pada halaman sebelumnya, operasi seperti pergerakan rekod juga boleh dilakukan dipanggil "pemisahan halaman".

Selain itu, mengapa muka surat baharu muka surat 28 dan bukan muka surat 11? Kerana halaman mungkin tidak bersebelahan antara satu sama lain pada cakera, mereka hanya mewujudkan hubungan senarai terpaut dengan mengekalkan nombor halaman sebelumnya dan halaman seterusnya.

2. Buat entri direktori untuk semua halaman

Sekarang teruskan menambah data pada jadual Hubungan akhir antara berbilang halaman adalah seperti berikut:

Untuk mencari rekod dengan cepat daripada berbilang halaman bukan bersebelahan, direktori perlu disusun untuknya, kerana halaman ini mungkin tidak bersebelahan pada cakera.

Setiap halaman sepadan dengan entri direktori, dan setiap entri direktori termasuk:

• Nilai kunci utama terkecil dalam rekod pengguna halaman, diwakili oleh kunci

• Nombor halaman, diwakili oleh page_no

Jadi, selepas mengkatalogkannya, hubungannya adalah seperti ini:

Jadi, sekarang saya ingin mencari rekod dengan nilai kunci utama 20. Secara khusus, terdapat dua langkah:

Gunakan kaedah dikotomi untuk menentukan rekod dengan nilai kunci primer dengan cepat 20 daripada entri direktori Item 3, dan ia berada di halaman 9. Mengetahui bahawa ia adalah pada halaman 9, ulangi pendekatan sebelumnya untuk mencari rekod sasaran akhir.

Pada ketika ini, penyelesaian mudah telah selesai. Direktori ringkas yang lengkap mempunyai alias yang dipanggil index.

3. Masalah yang didedahkan oleh indeks ringkas

Indeks ringkas yang disebutkan di atas ialah kandungan yang ditetapkan oleh pengarang buku asal untuk membantu pembaca memahami langkah demi langkah skim pengindeksan innodb.

Kemudian lihat indeks yang dicadangkan di atas dan lihat apakah masalah yang ada.

Soalan 1:

InnoDB menggunakan halaman sebagai unit asas untuk mengurus ruang storan, yang bermaksud ia hanya boleh menyimpan sehingga 16kb storan berterusan.

Apabila terdapat lebih banyak rekod dalam jadual, ruang storan berterusan yang sangat besar diperlukan untuk menyimpan semua entri direktori, yang tidak realistik untuk jadual dengan jumlah data yang besar.

Soalan 2:

Kita sering perlu menambah, memadam dan mengubah suai rekod, yang boleh menjejaskan seluruh badan.

Contohnya, jika saya memadamkan semua rekod pada halaman 28 dalam gambar di atas, maka halaman 28 tidak perlu wujud, dan entri direktori 2 tidak perlu wujud. Pada masa ini, anda perlu mengalihkan item direktori selepas item direktori 2 ke hadapan.

Walaupun ia tidak dialihkan, meletakkan entri direktori 2 sebagai berlebihan dalam senarai entri direktori masih akan membazirkan banyak ruang storan.

Atas ialah kandungan terperinci Analisis pelan indeks ringkas MySQL. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!