Ringkaskan dan susun soalan temu bual biasa tentang pangkalan data MySQL

Artikel ini membawakan anda pengetahuan yang berkaitan tentang mysql terutamanya ringkasan soalan temu duga untuk pengeluar pangkalan data. Saya harap ia dapat membantu semua orang.

Pembelajaran yang disyorkan: tutorial video mysql

1 🎜>

Borang Biasa Pertama (1NF): Ini bermakna lajur jadual tidak boleh dibahagikan lagi Setiap lajur jadual dalam pangkalan data ialah item data asas yang tidak boleh dibahagikan, dan tidak boleh terdapat berbilang nilai ​​dalam lajur yang sama;

Borang Normal Kedua (2NF): Berdasarkan 1NF, ia juga merangkumi dua bahagian: pertama, jadual mesti mempunyai kunci utama kedua, lajur bukan kunci utama dalam jadual mesti bergantung sepenuhnya pada kunci primer, dan tidak boleh hanya bergantung pada kunci primer Bahagian
• Bentuk normal ketiga (3NF): Berdasarkan 2NF, kebergantungan transitif lajur bukan kunci utama adalah. disingkirkan. Lajur bukan kunci utama mesti bergantung secara langsung pada kunci utama.
• BC Normal Form (BCNF): Berdasarkan 3NF, pergantungan transitif atribut utama pada bahagian kod dihapuskan

2. Proses pelaksanaan Pernyataan SQL:

2.1. Pemacu pangkalan data pelanggan dan kumpulan sambungan pangkalan data:

(1) Sebelum pelanggan berkomunikasi dengan pangkalan data, wujudkan sambungan dengan MySQL melalui pemacu pangkalan data , selepas penubuhan selesai, hantar pernyataan SQL

(2) Untuk mengurangkan kemerosotan prestasi sistem yang disebabkan oleh penciptaan dan pemusnahan sambungan yang kerap, sebilangan benang sambungan dikekalkan melalui kumpulan sambungan pangkalan data Apabila sambungan diperlukan, terus Dapatkannya dari kumpulan sambungan dan kembalikannya ke kumpulan sambungan selepas digunakan. Kumpulan sambungan pangkalan data biasa termasuk Druid, C3P0, DBCP

2.2 Proses pelaksanaan lapisan Pelayan seni bina MySQL:

(1) Penyambung: Terutamanya bertanggungjawab untuk. berkomunikasi dengan pelanggan Wujudkan sambungan, dapatkan kebenaran, simpan dan uruskan sambungan

(2) Cache pertanyaan: Tanya dalam cache dahulu, dan kembalikan terus jika pertanyaan tidak ditemui dalam cache, buat pertanyaan dalam pangkalan data.

Cache MySQL dimatikan secara lalai, yang bermaksud bahawa penggunaan cache tidak disyorkan dan keseluruhan fungsi cache pertanyaan telah dipadamkan dalam versi MySQL8.0. Ini disebabkan terutamanya oleh pengehadan senario penggunaannya:

Mari kita bincangkan dahulu tentang format storan data dalam cache: key (penyataan sql) - nilai (nilai data), jadi jika pernyataan SQL (kunci) hanya wujud Sedikit perbezaan akan membawa kepada pertanyaan pangkalan data langsung

Memandangkan data dalam jadual tidak statik, kebanyakannya berubah dengan kerap, dan apabila data dalam pangkalan data berubah, ia akan berkaitan; ke jadual ini dengan sewajarnya Data cache dari Dapatkan pepohon sintaks abstrak, dan kemudian gunakan prapemproses untuk melaksanakan pengesahan semantik pada pepohon sintaks abstrak untuk menentukan sama ada jadual dalam pepohon sintaks abstrak wujud, kemudian tentukan sama ada pilih medan lajur unjuran wujud dalam jadual, dsb.
• (4) Pengoptimum: Ia terutamanya menggunakan pokok sintaks yang diperolehi selepas analisis leksikal dan analisis sintaks SQL, melalui kandungan kamus data dan maklumat statistik, dan kemudian melalui satu siri operasi untuk akhirnya mendapatkan pelaksanaan pelan, termasuk Memilih indeks yang hendak digunakan

Semasa menganalisis sama ada hendak menggunakan pertanyaan indeks, ia ditentukan dengan melakukan

analisis statistik pensampelan data dinamik

selagi ia dianalisis secara statistik , mungkin

Terdapat ralat analisis

, jadi apabila melaksanakan SQL tanpa pengindeksan, faktor ini juga mesti diambil kira

(5) Pelaksana: Dipanggil mengikut satu siri pelan pelaksanaan Antara muka API yang disediakan oleh enjin storan digunakan untuk memanggil data operasi dan melengkapkan pelaksanaan SQL. 2.3. Proses pelaksanaan enjin storan Innodb:

• (1) Pertama, pelaksana MySQL memanggil API enjin storan untuk menanyakan data mengikut pelan pelaksanaan
• (2) Enjin storan terlebih dahulu menanyakan data daripada kumpulan penimbal, jika tidak, Ia akan menanyakan cakera, dan jika pertanyaan ditemui, ia akan diletakkan dalam kumpulan penimbal
• (3) Semasa data dimuatkan ke dalam Kolam Penampan, rekod asal bagi data ini akan disimpan ke fail log buat asal
• (4) innodb akan melakukan operasi kemas kini dalam Kolam Penampan
• (5) Data yang dikemas kini akan direkodkan dalam penimbal log buat semula
• (6) Transaksi yang diserahkan diserahkan Pada masa yang sama, ia akan melakukan tiga perkara berikut
• (7) (perkara pertama) siram data dalam penimbal log buat semula ke dalam buat semula fail log
• (8) (perkara kedua) Perkara) Tulis rekod operasi ini ke dalam fail log bin
• (9) (Perkara ketiga) Catatkan nama fail log tong dan lokasi kandungan yang dikemas kini dalam log sampah ke dalam log buat semula, dan pada masa yang sama Tambah tanda komit
• di penghujung log buat semula (10) Gunakan utas latar belakang, yang akan mengepam kemas kini data dalam Buffer Pool kami ke pangkalan data MySQL pada peluang tertentu, dengan itu menggabungkan memori dan pangkalan data Data kekal bersatu

3. Enjin storan yang biasa digunakan? Apakah perbezaan antara InnoDB dan MyISAM?

Enjin storan ialah komponen yang melaksanakan operasi sebenar pada data fizikal asas dan menyediakan pelbagai API untuk data pengendalian untuk lapisan perkhidmatan Pelayan. Enjin storan yang biasa digunakan termasuk InnoDB, MyISAM dan Memory. Di sini kami terutamanya memperkenalkan perbezaan antara InnoDB dan MyISAM:

(1) Transaksi: MyISAM tidak menyokong transaksi, InnoDB menyokong transaksi

(2) Tahap kunci: MyISAM hanya menyokong kunci peringkat jadual , InnoDB melakukan kunci peringkat Baris dan kunci peringkat jadual, kunci peringkat baris digunakan secara lalai, tetapi kunci baris hanya akan digunakan apabila menanya data melalui indeks, jika tidak, kunci jadual akan digunakan. Kunci peringkat baris menggunakan lebih banyak sumber daripada kunci meja dalam setiap operasi memperoleh dan melepaskan kunci. Mungkin terdapat kebuntuan apabila menggunakan kunci baris, tetapi tiada kebuntuan dengan kunci peringkat jadual

(3) Kekunci utama dan kekunci asing: MyISAM membenarkan jadual tanpa sebarang indeks dan kunci utama wujud, dan tidak menyokong kunci asing. Kunci utama InnoDB tidak boleh kosong dan menyokong pertumbuhan auto kunci primer Jika tiada kunci utama atau indeks unik bukan kosong ditetapkan, kunci utama 6 bait akan dijana secara automatik dan menyokong kekangan integriti kunci asing

(. 4) Struktur Indeks: Kedua-dua MyISAM dan InnoDB menggunakan indeks B-tree Medan Data indeks kunci utama dan indeks tambahan MyISAM ialah alamat tempat rekod data baris disimpan. Walau bagaimanapun, medan Data indeks kunci utama InnoDB tidak menyimpan alamat rekod data baris, tetapi semua kandungan data baris, manakala medan Data indeks tambahan menyimpan nilai indeks utama.

Memandangkan indeks tambahan InnoDB menyimpan nilai indeks kunci utama, menggunakan indeks tambahan memerlukan mendapatkan semula indeks dua kali: pertama, dapatkan indeks tambahan untuk mendapatkan kunci utama, dan kemudian gunakan kunci utama untuk mendapatkan semula rekod dalam indeks utama. Inilah sebabnya mengapa tidak disyorkan untuk menggunakan medan terlalu panjang sebagai kunci utama: memandangkan indeks tambahan mengandungi lajur kunci utama, jika kunci utama menggunakan medan terlalu panjang, ia akan menyebabkan indeks tambahan lain menjadi lebih besar, jadi cuba tentukan kunci utama sekecil mungkin.

(5) Indeks teks penuh: MyISAM menyokong indeks teks penuh InnoDB tidak menyokong indeks teks penuh sebelum versi 5.6 dan kemudian mula menyokong indeks teks penuh

(6) Jadual Bilangan baris tertentu:

• ① MyISAM: Menyimpan jumlah bilangan baris dalam jadual Jika anda menggunakan pilih count() daripada jadual, nilai akan diambil keluar terus tanpa memerlukan imbasan meja penuh.
• ② InnoDB: Jumlah bilangan baris dalam jadual tidak disimpan Jika anda menggunakan pilih count() daripada jadual, anda perlu melintasi keseluruhan jadual, yang menggunakan banyak wang.

(7) Struktur storan:

• ① MyISAM akan menyimpan tiga fail pada cakera: fail .frm untuk menyimpan definisi jadual, fail .MYD untuk menyimpan data, . Indeks storan fail MYI.
• ② InnoDB: Simpan data dan indeks dalam ruang jadual Semua jadual disimpan dalam fail data yang sama Saiz jadual InnoDB hanya dihadkan oleh saiz fail sistem pengendalian, yang biasanya 2GB .

(8) Ruang storan:

• ① MyISAM: Boleh dimampatkan dan mempunyai ruang storan yang lebih kecil. Menyokong tiga format storan berbeza: jadual statik (lalai, tetapi sila ambil perhatian bahawa mesti tiada ruang di hujung data, ia akan dialih keluar), jadual dinamik dan jadual dimampatkan.
• ② InnoDB: Memerlukan lebih banyak memori dan storan. Ia akan mewujudkan kumpulan penimbal khusus dalam memori utama untuk menyimpan data dan indeks.

(9) Senario yang berkenaan:

• ① Jika anda perlu menyediakan keupayaan transaksi ACID dengan keupayaan pemulihan dan pemulihan ranap, dan memerlukan kawalan konkurensi tahap kunci baris, InnoDB ialah Pilihan yang baik;
• ② Jika jadual data digunakan terutamanya untuk menanyakan rekod, operasi baca adalah jauh lebih banyak daripada operasi tulis, dan sokongan transaksi pangkalan data tidak diperlukan, enjin MyISAM boleh menyediakan pemprosesan yang lebih tinggi kecekapan;

Nota: Enjin storan MyISAM telah ditinggalkan dalam versi mysql8.0

4 urus niaga?

Transaksi pangkalan data ialah unit asas kawalan serentak Ia merujuk kepada set operasi logik, sama ada kesemuanya dilaksanakan atau tiada satu pun daripadanya dilaksanakan.

4.1. ASID transaksi:

• (1) Atomicity: Transaksi ialah unit kerja yang tidak boleh dibahagikan dalam transaksi sama ada berjaya atau gagal, ia perlu dibatalkan.
• (2) Pengasingan: Tahap sejauh mana data yang dikendalikan oleh transaksi dapat dilihat oleh transaksi lain sebelum diserahkan.
• (3) Kegigihan: Setelah transaksi dilakukan, perubahannya kepada data dalam pangkalan data adalah kekal.
• (4) Ketekalan: Transaksi tidak boleh memusnahkan integriti data dan konsistensi perniagaan. Sebagai contoh, apabila memindahkan wang, sama ada transaksi berjaya atau gagal, jumlah wang antara kedua-dua pihak kekal tidak berubah.

4.2. Prinsip pelaksanaan ACID:

4.2.1 Atomicity: Atomicity melalui log balik balik MySQL来Dilaksanakan: Apabila. urus niaga mengubah suai pangkalan data, InnoDB akan menjana log buat asal yang sepadan jika pelaksanaan urus niaga gagal atau panggil balik, menyebabkan urus niaga ditarik balik, maklumat dalam log buat asal boleh digunakan untuk melancarkan semula data kepada pengubahsuaian. Caranya dulu.

4.2.2. Pengasingan:

(1) Tahap pengasingan transaksi:

Untuk memastikan bahawa dalam persekitaran serentak Pangkalan data menyediakan empat tahap pengasingan transaksi untuk memastikan integriti dan konsistensi data yang dibaca Lebih tinggi tahap pengasingan, lebih baik integriti dan konsistensi data boleh dijamin, tetapi lebih besar kesan ke atas prestasi konkurensi yang tinggi dan lebih rendah pelaksanaannya. kecekapan. (Empat tahap pengasingan meningkat dari atas ke bawah)

• Baca tanpa komitmen: membenarkan urus niaga membaca data tanpa komitmen transaksi lain semasa pelaksanaan; baca data yang dihantar oleh transaksi lain semasa pelaksanaan;
• Baca Berulang (peringkat lalai): Dalam transaksi yang sama, hasil pertanyaan pada bila-bila masa adalah konsisten
• Siri baca: Semua transaksi dilaksanakan satu oleh satu. Setiap bacaan perlu mendapatkan kunci kongsi peringkat jadual, dan membaca dan menulis akan menyekat satu sama lain.

(2) Isu konkurensi transaksi:

Jika pengasingan transaksi tidak dipertimbangkan, mungkin terdapat masalah dalam persekitaran konkurensi transaksi Di sana ialah:

Kemas kini hilang: apabila dua atau lebih transaksi beroperasi pada data yang sama dan kemudian mengemas kini baris berdasarkan nilai yang dipilih, kerana setiap transaksi tidak mengetahui kewujudan transaksi lain , masalah kemas kini hilang berlaku: kemas kini terakhir menimpa kemas kini yang dibuat oleh transaksi lain.

• Bacaan kotor: bermakna transaksi A sedang mengakses data dan telah mengubah suai data (urus niaga tidak dilakukan pada masa ini, urus niaga B juga menggunakan data ini Kemudian, urus niaga A membatalkan pengembalian dan menukarnya data yang diubah suai. Apabila data dipulihkan kepada nilai asalnya, data yang dibaca oleh B adalah tidak konsisten dengan data dalam pangkalan data, iaitu data yang dibaca oleh B adalah data yang kotor.
• Bacaan tidak boleh berulang: dalam urus niaga, data yang sama dibaca berbilang kali, tetapi kerana transaksi lain mengubah suai dan melakukan data dalam tempoh ini, data yang dibaca sebelum dan selepas adalah tidak konsisten; >Bacaan hantu: Dalam urus niaga, data yang sama (biasanya pertanyaan julat) dibaca dua kali, tetapi kerana transaksi lain menambah atau memadam data, keputusan dua masa itu tidak konsisten.
• Tahap pengasingan transaksi yang berbeza akan mempunyai masalah konkurensi yang berbeza dalam persekitaran serentak:

(3) Prinsip Pelaksanaan Transaksi pengasingan:

Tahap pengasingan transaksi Innodb dilaksanakan oleh MVVC dan mekanisme kunci: ① MVCC (Multi-Version Concurrency Control, multi-version concurrency control) ialah A khusus cara untuk enjin storan InnoDB MySQL untuk melaksanakan tahap pengasingan transaksi adalah dengan melaksanakan dua tahap pengasingan: baca komited dan bacaan boleh berulang. Tahap pengasingan tanpa komitmen membaca sentiasa membaca baris data terkini tanpa menggunakan MVCC. Tahap pengasingan bersiri baca memerlukan mengunci semua baris baca, yang tidak boleh dicapai hanya menggunakan MVCC.

MVCC dilaksanakan dengan menyimpan dua lajur tersembunyi di belakang setiap baris rekod, satu menyimpan ID transaksi baris dan satu lagi menyimpan penuding segmen gulung balik baris. Setiap kali transaksi baharu dimulakan, ID transaksi baharu akan dinaikkan secara automatik. Apabila urus niaga bermula, ID transaksi akan diletakkan dalam medan ID urus niaga baris yang terjejas oleh urus niaga semasa dan penunjuk segmen putar balik mengandungi semua data versi pada rekod baris, yang disusun dalam bentuk terpaut senarai dalam log gulung balik log asal, iaitu Dikatakan bahawa nilai sebenarnya menunjukkan kepada senarai terpaut sejarah bagi baris dalam log buat asal.

Apabila mengakses pangkalan data secara serentak, pengurusan berbilang versi MVCC dilakukan pada data dalam urus niaga untuk mengelakkan operasi tulis menyekat operasi baca, dan masalah bacaan hantu bacaan syot kilat boleh diselesaikan dengan membandingkan versi, tetapi untuk MVCC semasa tidak dapat menyelesaikan bacaan hantu dan perlu diselesaikan melalui kunci kunci sementara.

② Mekanisme kunci:

Prinsip kerja asas mekanisme kunci MySQL ialah: sebelum transaksi mengubah suai pangkalan data, ia perlu mendapatkan kunci yang sepadan Hanya transaksi yang memperoleh kunci boleh ubah suai data; dalam urus niaga ini Semasa operasi, bahagian data ini dikunci Jika transaksi lain perlu mengubah suai data, mereka perlu menunggu urus niaga semasa melakukan atau melancarkan semula untuk melepaskan kunci.

• Kunci eksklusif menyelesaikan bacaan kotor
• Kunci dikongsi menyelesaikan bacaan tidak boleh berulang
• Kunci pro-kunci menyelesaikan bacaan hantu

4.2.3 Kegigihan:

Kegigihan bergantung pada log buat semula ，Apabila melaksanakan SQL, pernyataan SQL yang dilaksanakan akan disimpan ke fail log buat semula, tetapi untuk meningkatkan kecekapan, data adalah ditulis Sebelum memasukkan log buat semula, ia akan ditulis ke cache penimbal log buat semula dalam ingatan. Proses penulisan adalah seperti berikut: Apabila menulis data ke pangkalan data, proses pelaksanaan akan menulis terlebih dahulu kepada penimbal log buat semula, dan data yang diubah suai dalam penimbal log buat semula akan sentiasa dimuat semula ke fail log buat semula pada cakera Proses ini dipanggil pembilasan cakera (iaitu Penampan log buat semula menulis log ke fail log buat semula pada cakera).

Penggunaan penampan log semula boleh meningkatkan kecekapan membaca dan menulis data, tetapi ia juga membawa masalah baharu: jika MySQL rosak, data yang diubah suai dalam penimbal log semula masih berada dalam memori. Kegagalan untuk mengepam ke cakera akan mengakibatkan kehilangan data, dan ketahanan transaksi tidak dapat dijamin. Untuk memastikan ketahanan urus niaga, apabila urus niaga dilakukan, antara muka fsync akan dipanggil untuk mengepam log buat semula Frekuensi muat semula dikawal oleh pembolehubah innodb_flush_log_at_trx_commit:

• 0: bermakna. untuk tidak mengepam cakera;
• 1: Setiap kali transaksi diserahkan, data dalam kumpulan penimbal disiram ke cakera
• 2: Apabila transaksi diserahkan, data masuk kolam penimbal ditulis pada fail cakera Pergi ke cache cache os yang sepadan dan bukannya terus memasuki fail cakera. Ia mungkin mengambil masa 1 saat sebelum data dalam cache os ditulis ke fail cakera.

4.2.4 Ketekalan:

Konsistensi bermaksud transaksi tidak boleh memusnahkan integriti data dan konsistensi perniagaan:

• Integriti data: integriti entiti, integriti lajur (seperti jenis medan, saiz, panjang mesti memenuhi keperluan), kekangan kunci asing, dsb.

• Konsistensi perniagaan: Contohnya, dalam bank pemindahan, sama ada transaksi berjaya atau gagal, jumlah wang antara kedua-dua pihak kekal tidak berubah.

5. Apakah mekanisme penguncian dalam pangkalan data?

Apabila berbilang transaksi dalam pangkalan data secara serentak mengakses data yang sama, jika operasi serentak tidak dikawal, data yang salah mungkin dibaca dan disimpan, memusnahkan konsistensi pangkalan data. Prinsip kerja asas mekanisme kunci MySQL ialah sebelum urus niaga mengubah pangkalan data, ia perlu mendapatkan kunci yang sepadan Hanya urus niaga yang memperoleh kunci boleh mengubah suai data semasa operasi transaksi, bahagian ini data dikunci jika transaksi lain Jika data perlu diubah suai, kunci perlu dilepaskan selepas transaksi semasa dilakukan atau digulung semula.

Mengikut kaedah pengelasan yang berbeza, jenis kunci boleh dibahagikan kepada jenis berikut:

• Mengikut butiran kunci: peringkat meja kunci, kunci peringkat baris , kunci peringkat halaman;
• Dibahagikan dengan jenis kunci: dikongsi (kunci Kunci S), kunci eksklusif (kunci X); kunci, kunci pesimis;

5.1, kunci peringkat jadual, kunci peringkat baris, kunci peringkat halaman:

Kunci peringkat jadual: kebutiran maksimum Tahap kunci mempunyai kebarangkalian konflik kunci yang paling tinggi dan konkurensi yang paling rendah, tetapi overhed adalah kecil, kunci adalah pantas, dan jalan buntu tidak akan berlaku; kunci: Kebutiran terkecil dari semua peringkat, kebarangkalian konflik kunci Tahap penyelarasan yang paling kecil, tertinggi, tetapi overhed tinggi, penguncian perlahan dan kebuntuan akan berlaku;

• Kunci peringkat halaman: Butiran kunci adalah terhad antara kunci peringkat meja dan kunci peringkat baris Kunci adalah kompromi dan konkurensi adalah purata. Masa overhed dan penguncian juga dihadkan antara kunci meja dan kunci baris, dan kebuntuan akan berlaku; 🎜>Enjin storan InnoDB menyokong kunci peringkat baris dan kunci peringkat meja Secara lalai, kunci peringkat baris digunakan, tetapi kunci peringkat baris hanya digunakan apabila data disoal melalui indeks Jika tidak, kunci peringkat jadual digunakan.
• Enjin storan MyISAM dan MEMORY menggunakan kunci peringkat meja;
• Enjin storan BDB menggunakan kunci halaman, tetapi juga menyokong kunci peringkat meja;
5.2. Kunci baris InnoDB:

Kunci baris InnoDB mempunyai dua jenis:

Kunci kongsi (kunci S, baca kunci): berbilang Transaksi boleh berkongsi Kunci S pada baris data yang sama, tetapi ia hanya boleh membaca dan tidak boleh mengubah suai
• Kunci eksklusif (kunci X, kunci tulis): Selepas transaksi memperoleh kunci eksklusif, ia boleh menukar julat kunci Semasa kunci tempoh, urus niaga lain tidak lagi boleh mendapatkan kunci (kunci kongsi, kunci eksklusif) bahagian baris data ini, dan hanya transaksi yang memperoleh kunci eksklusif dibenarkan untuk mengemas kini data.
• Untuk operasi kemas kini, padam dan sisipan, InnoDB akan menambah kunci eksklusif secara automatik pada baris data yang terlibat untuk pernyataan SELECT biasa, InnoDB tidak akan menambah sebarang kunci.

5.3. Kunci jadual InnoDB dan kunci niat:

Oleh kerana enjin InnoDB membenarkan kunci baris dan kunci meja wujud bersama, melaksanakan mekanisme penguncian berbutir-butir , tetapi Walaupun kunci meja dan kunci baris mempunyai skop penguncian yang berbeza, ia akan bercanggah antara satu sama lain. Apabila anda ingin menambah kunci meja, anda mesti terlebih dahulu melintasi semua rekod dalam jadual untuk menentukan sama ada terdapat kunci eksklusif. Kaedah semakan traversal ini jelas merupakan cara yang tidak cekap MySQL memperkenalkan kunci niat untuk mengesan konflik antara kunci meja dan kunci baris.

Kunci niat juga adalah kunci peringkat meja, dibahagikan kepada kunci niat baca (kunci IS) dan kunci niat tulis (kunci IX). Apabila transaksi ingin menambah kunci baris pada rekod, ia terlebih dahulu menambahkan kunci niat yang sepadan pada jadual. Jika transaksi kemudiannya ingin mengunci jadual, ia hanya perlu terlebih dahulu menentukan sama ada kunci yang dimaksudkan wujud Jika wujud, ia boleh kembali ke jadual dengan cepat, jika tidak, ia perlu menunggu untuk meningkatkan kecekapan.

5.4 Pelaksanaan kunci baris InnoDB dan kunci kunci sementara:

Kunci baris InnoDB dilaksanakan dengan mengunci item indeks pada indeks. Kunci baris hanya boleh digunakan apabila data diambil melalui indeks, jika tidak, kunci jadual akan digunakan.

Dalam InnoDB, untuk menyelesaikan fenomena bacaan hantu, kunci kekunci seterusnya (kekunci seterusnya) diperkenalkan. Mengikut indeks, ia dibahagikan kepada selang dengan kiri terbuka dan kanan tertutup. Apabila melakukan pertanyaan julat, jika indeks dipukul dan data boleh diambil semula, selang tempat rekod berada dan selang seterusnya akan dikunci. Malah, Next-Key = Kunci Rekod Jurang Kunci

• Kunci Jurang: Apabila menggunakan pertanyaan julat dan bukannya pertanyaan tepat untuk mendapatkan data, Apabila meminta kunci kongsi atau eksklusif, InnoDB akan mengunci item indeks rekod data sedia ada yang memenuhi syarat julat; untuk rekod yang nilai utamanya berada dalam julat keadaan tetapi tidak wujud, ia dipanggil jurang (GAP).
• Kunci rekod: Apabila menggunakan indeks unik dan pertanyaan kewujudan rekod yang tepat, gunakan kunci rekod

5.5.

• 🎜>
Untuk butiran mengenai mekanisme penguncian enjin storan InnoDB dan mekanisme penguncian enjin storan MyISAM, anda boleh membaca artikel ini: Pangkalan Data MySQL: Mekanisme Mengunci_ Blog-CSDN Blog_Mekanisme Mengunci Zhang Weipeng dalam Pangkalan Data
• 6 Prinsip pelaksanaan indeks MySQL:

Indeks pada asasnya ialah struktur data yang mempercepatkan. prestasi pertanyaan dengan mengurangkan bilangan baris yang perlu dilalui dalam pertanyaan

Halang pangkalan data daripada melakukan imbasan jadual penuh, sama seperti jadual kandungan buku, membolehkan anda mencari kandungan dengan lebih cepat. (Sesuatu jadual boleh mempunyai sehingga 16 indeks)

6.1 Kebaikan dan keburukan indeks:

(1) Kelebihan indeks:

<.>

Kurangkan bilangan baris yang perlu diambil oleh pertanyaan, percepatkan pertanyaan dan elakkan imbasan jadual penuh Ini juga merupakan sebab utama untuk mencipta indeks. Jika struktur data indeks ialah pokok B, apabila menggunakan pengumpulan dan pengisihan, masa pengumpulan dan pengisihan dalam pertanyaan boleh dikurangkan dengan ketara.

Dengan mencipta indeks yang unik, anda boleh memastikan keunikan setiap baris data dalam jadual pangkalan data.

(2) Kelemahan indeks:
• Apabila data dalam jadual ditambah, dipadam dan diubah suai, indeks juga mesti dikemas kini, dan masa penyelenggaraan akan meningkat dengan masa meningkat dengan jumlah data.
• Indeks perlu menduduki ruang fizikal Jika anda ingin mencipta indeks berkelompok, ruang yang diperlukan akan lebih besar.

6.2. Senario penggunaan indeks:
• (1) Pada lajur untuk membuat indeks:

Buat indeks pada lajur yang kerap muncul dalam klausa WHERE untuk mempercepatkan penghakiman syarat. Lajur yang diakses mengikut julat atau lajur yang digunakan dalam kumpulan mengikut atau susunan mengikut, kerana indeks telah diisih, jadi indeks boleh digunakan untuk mempercepatkan masa penyisihan pertanyaan.

sering digunakan pada lajur yang disambungkan terutamanya kekunci asing, yang boleh mempercepatkan sambungan

digunakan sebagai lajur kunci utama untuk menguatkuasakan keunikan lajur dan mengaturkan. jadual. Struktur susunan data;

• Lajur yang tidak begitu boleh dibezakan. Memandangkan lajur ini mempunyai nilai yang sangat sedikit, seperti jantina, dalam hasil pertanyaan, baris data dalam set hasil mengambil kira sebahagian besar baris data dalam jadual, iaitu, sebahagian besar baris data perlu dicari dalam jadual. Meningkatkan indeks tidak secara signifikan mempercepatkan pencarian semula.
• Lajur yang jarang digunakan dalam pertanyaan tidak boleh diindeks. Oleh kerana lajur ini jarang digunakan, penambahan indeks sebenarnya akan mengurangkan kelajuan penyelenggaraan sistem dan meningkatkan keperluan ruang.
• Apabila menambah indeks menyebabkan peningkatan dalam kos pengubahsuaian menjadi jauh lebih besar daripada peningkatan dalam prestasi perolehan semula, indeks tidak seharusnya dibuat. Apabila menambah indeks, prestasi perolehan semula akan dipertingkatkan, tetapi prestasi pengubahsuaian akan dikurangkan. Apabila mengurangkan indeks, prestasi pengubahsuaian akan meningkat dan prestasi perolehan semula akan berkurangan.
• Lajur yang ditakrifkan sebagai teks, imej dan jenis data bit tidak boleh diindeks. Jumlah data lajur ini sama ada agak besar atau mempunyai nilai yang sangat sedikit.

• 6.3. Klasifikasi indeks:
• (1) Indeks biasa, indeks unik, indeks kunci primer, indeks teks penuh, indeks gabungan.

• • Indeks biasa: Indeks paling asas, tanpa sebarang sekatan
  • Indeks unik: Tetapi nilai lajur indeks mestilah unik, nilai nol dibenarkan, dan boleh menjadi berbilang nilai NULL. Dalam kes indeks komposit, gabungan nilai lajur mestilah unik.
  • Indeks kunci utama: indeks unik khas yang tidak membenarkan nilai nol.
  • Indeks teks penuh: Indeks teks penuh hanya boleh digunakan untuk jadual MyISAM, dan hanya menyokong jenis CHAR, VARCHAR atau TEXT Ia digunakan untuk menggantikan operasi pemadanan kabur yang kurang cekap, dan boleh digabungkan dengan indeks teks penuh berbilang medan sekaligus Padanan kabur penuh berbilang medan.
  • Indeks gabungan: Terutamanya untuk meningkatkan kecekapan mysql, apabila mencipta indeks komposit, lajur yang paling biasa digunakan sebagai syarat sekatan hendaklah diletakkan di bahagian paling kiri, dalam susunan menurun.

  (2) Indeks berkelompok dan indeks bukan berkelompok:

  Jika dikelaskan mengikut susunan fizikal penyimpanan data dan susunan nilai indeks, indeks boleh dibahagikan kepada indeks berkelompok dan indeks tidak berkelompok Terdapat dua jenis indeks berkelompok dan indeks tidak berkelompok:

  • Indeks berkelompok: Susunan fizikal storan data dalam jadual adalah konsisten dengan. susunan nilai indeks. Jadual asas hanya boleh mempunyai satu kluster paling banyak, apabila mengemas kini data pada lajur indeks berkelompok, ia sering membawa kepada perubahan dalam susunan fizikal dalam jadual, yang memerlukan kos adalah tidak sesuai untuk mewujudkan indeks berkelompok untuk lajur yang kerap dikemas kini
  • Indeks tidak berkelompok: jadual Dalam organisasi indeks di mana susunan fizikal data tidak konsisten dengan susunan nilai indeks, jadual asas boleh mempunyai berbilang kelompok indeks.

  6.4. Struktur data indeks:

  Struktur data indeks biasa termasuk: B Tree, indeks Hash.

  (1) Indeks cincang: Hanya enjin storan Memori dalam MySQL menyokong indeks cincang, yang merupakan jenis indeks lalai bagi jadual Memori. Indeks cincang menyusun data dalam bentuk nilai cincang, jadi kecekapan pertanyaan adalah sangat tinggi dan boleh dikesan pada satu masa.

  Kelemahan indeks cincang:

  • Indeks cincang hanya boleh memenuhi pertanyaan nilai yang sama, tetapi tidak boleh memenuhi pertanyaan julat dan pengisihan. Kerana selepas data melalui algoritma Hash, perhubungan saiznya mungkin berubah.
  • Apabila mencipta indeks komposit, anda tidak boleh membuat pertanyaan menggunakan beberapa lajur indeks komposit sahaja. Oleh kerana indeks cincang menggabungkan berbilang data lajur dan kemudian mengira nilai Hash, adalah tidak bermakna untuk mengira nilai Hash untuk data lajur individu.
  • Apabila perlanggaran Hash berlaku, indeks Hash tidak dapat mengelakkan pengimbasan data jadual. Kerana tidak cukup dengan hanya membandingkan nilai Hash, anda perlu membandingkan nilai sebenar untuk menentukan sama ada ia memenuhi keperluan.

  (2) B Tree index: B Tree ialah struktur data indeks yang paling kerap digunakan dalam mysql Ia adalah jenis indeks mod enjin storan Innodb dan Myisam. Indeks B Tree memerlukan berbilang operasi IO dari nod akar ke nod daun semasa carian Kelajuan pertanyaan tidak sebagus indeks Hash, tetapi ia lebih sesuai untuk operasi seperti pengisihan.

  Kelebihan indeks B Tree:

  • Nod dalam halaman tidak menyimpan kandungan, dan lebih banyak baris boleh dibaca bagi setiap IO, dengan banyak mengurangkan bacaan I/O cakera Masa
  • B Tree dengan penunjuk capaian berjujukan: Semua data indeks B Tree disimpan pada nod daun, dan penunjuk capaian berjujukan ditambah Setiap nod daun mempunyai penunjuk ke nod daun bersebelahan, jadi Ini dilakukan untuk menambah baik kecekapan pertanyaan selang waktu.

  6.5 Mengapa menggunakan B Tree sebagai indeks:

  Indeks itu sendiri juga sangat besar dan mustahil untuk menyimpan semuanya dalam ingatan. , jadi Indeks selalunya disimpan pada cakera dalam bentuk fail indeks. Dalam kes ini, penggunaan I/O cakera akan dijana semasa proses carian indeks Berbanding dengan akses memori, penggunaan akses I/O cakera adalah beberapa urutan magnitud yang lebih tinggi struktur data sebagai indeks Metrik penting ialah kerumitan asimptotik bilangan operasi I/O cakera semasa proses carian. Dalam erti kata lain, struktur data indeks harus meminimumkan bilangan akses I/O cakera semasa proses carian.

  (1) Prinsip lokaliti dan pra-bacaan program:

  Memandangkan cakera itu sendiri jauh lebih perlahan untuk diakses daripada memori utama, ditambah dengan penggunaan pergerakan mekanikal, mengikut urutan untuk meningkatkan kecekapan, Disk I/O harus diminimumkan. Untuk mencapai matlamat ini, cakera selalunya tidak membaca secara ketat atas permintaan, tetapi membaca terlebih dahulu setiap kali Walaupun hanya satu bait diperlukan, cakera akan bermula dari kedudukan ini dan secara berurutan membaca panjang tertentu data ke belakang ke dalam. ingatan. Asas teori untuk ini ialah prinsip lokaliti yang terkenal dalam sains komputer: apabila sekeping data digunakan, data berdekatan biasanya akan digunakan serta-merta. Data yang diperlukan semasa pelaksanaan program biasanya tertumpu.

  Memandangkan bacaan jujukan cakera adalah sangat cekap (tiada masa carian, masa putaran yang sangat sedikit), untuk program dengan lokaliti, baca ke hadapan boleh Meningkatkan kecekapan I/O. Panjang bacaan ke hadapan biasanya merupakan gandaan penting halaman. Apabila data yang akan dibaca oleh program tidak berada dalam memori utama, pengecualian kesalahan halaman akan dicetuskan Pada masa ini, sistem akan menghantar isyarat baca ke cakera, dan cakera akan mencari kedudukan permulaan data dan baca satu atau beberapa halaman ke belakang Muatkan ke dalam memori, kemudian kembali secara tidak normal, dan program terus berjalan.

  (2) Analisis prestasi indeks Pokok B:

  Seperti yang dinyatakan di atas, masa I/O cakera biasanya digunakan untuk menilai kualiti struktur indeks. Mari kita mulakan dengan analisis B-tree Pengambilan semula B-tree memerlukan akses kepada sehingga h nod Pada masa yang sama, pangkalan data bijak menggunakan prinsip cakera baca-depan untuk menetapkan saiz nod sama dengan satu halaman. iaitu, setiap kali nod baharu dicipta, aplikasi langsung dibuat Ruang halaman, ini memastikan bahawa nod disimpan secara fizikal dalam halaman, dan peruntukan storan komputer diselaraskan dengan halaman, supaya setiap nod boleh dimuatkan sepenuhnya. dengan hanya satu I/O. Pendapatan semula dalam pokok B memerlukan paling banyak h-1 I/O (nod akar bermastautin dalam ingatan), dan kerumitan masa ialah O(h)=O(logdN). Dalam aplikasi praktikal umum, darjah keluar d ialah nombor yang sangat besar, biasanya lebih daripada 100, jadi h adalah sangat kecil. Sebagai kesimpulan, menggunakan B-tree sebagai struktur indeks adalah sangat cekap.

  Walaupun kerumitan masa struktur pokok merah-hitam juga O(h), h jelas lebih mendalam, dan kerana nod yang secara logik dekat mungkin jauh dari segi fizikal, ia tidak boleh Mengambil kesempatan daripada lokaliti, kecekapan IO jelas lebih teruk daripada B-tree.

  Selain itu, B Tree lebih sesuai sebagai struktur data indeks, dan sebabnya adalah berkaitan dengan keluar-darjah d nod dalaman. Daripada analisis di atas, kita dapat melihat bahawa lebih besar d, lebih baik prestasi indeks, dan had atas darjah keluar d bergantung pada saiz kunci dan data dalam nod Memandangkan medan data dialih keluar daripada nod dalam B Tree, ia boleh mempunyai darjah keluar yang lebih besar, bilangan IO cakera akan menjadi kurang.

  (3) Perbandingan antara indeks B-tree dan B-tree index?

  Mengikut struktur B-Tree dan B Tree, kita dapati B-Tree mempunyai lebih banyak kelebihan berbanding B-Tree dalam sistem fail atau sistem pangkalan data adalah seperti berikut:

  • (1) B-tree kondusif untuk pengimbasan pangkalan data: B-tree meningkatkan prestasi cakera IO tetapi tidak menyelesaikan masalah ketidakcekapan lintasan elemen, manakala B-tree hanya perlu merentasi nod daun untuk menyelesaikan semua masalah Mengimbas maklumat kata kunci, jadi B-tree mempunyai prestasi yang lebih tinggi untuk operasi seperti pertanyaan julat dan pengisihan.
  • (2) Kos cakera IO bagi B-tree adalah lebih rendah: medan data nod dalaman B-tree tidak menyimpan data, jadi nod dalamannya lebih kecil daripada B-tree. Jika semua kata kunci nod dalaman yang sama disimpan dalam blok cakera yang sama, lebih banyak kata kunci yang boleh disimpan oleh blok cakera. Lebih banyak kata kunci yang perlu dicari dibaca ke dalam ingatan pada satu masa, dan bilangan I/O membaca dan menulis agak berkurangan.
  • (3) Kecekapan pertanyaan B-tree adalah lebih stabil: kerana nod dalaman B-tree hanyalah indeks kata kunci dalam nod daun dan tidak menyimpan data. Oleh itu, sebarang carian kata kunci mesti mengambil laluan dari nod akar ke nod daun. Panjang laluan semua pertanyaan kata kunci adalah sama, menghasilkan kecekapan pertanyaan yang sama untuk setiap data.

  (4) Pelaksanaan indeks B Tree dalam enjin storan InnoDB dan MyISAM MySQL?

  Kedua-dua MyISAM dan InnoDB menggunakan indeks B-tree Medan Data indeks kunci utama MyISAM dan indeks tambahan kedua-duanya menyimpan alamat baris, tetapi indeks kunci utama InnoDB tidak menyimpan alamat baris. , tetapi baris Semua data, manakala medan Data indeks tambahan menyimpan nilai indeks utama.

  Had panjang indeks:

  • Untuk indeks gabungan Innodb, jika panjang setiap lajur melebihi 767 bait, lajur yang melebihi 767 bait akan menjadi Ambil indeks awalan untuk Indeks lajur tunggal Innodb, jika panjang lajur melebihi 767, ambil indeks awalan (ambil 255 aksara pertama)
  • Untuk indeks gabungan MyISAM, jumlah panjang indeks yang dicipta tidak boleh melebihi 1000 bait , jika tidak ralat akan dilaporkan dan penciptaan akan gagal; untuk indeks lajur tunggal MyISAM, panjang maksimum tidak boleh melebihi 1000, jika tidak, penggera akan dikeluarkan, tetapi penciptaan berjaya, dan penciptaan akhir ialah indeks awalan (ambil 333 aksara pertama)

  7. Pengoptimuman SQL, pengoptimuman indeks, pengoptimuman struktur jadual:

  (1) Pengoptimuman SQL dan pengoptimuman indeks MySQL: https:/ /blog.csdn.net/a745233700 /article/details/84455241

  (2) Pengoptimuman struktur jadual MySQL: https://blog.csdn.net/a745233700/article/details/84405087

  8. Pengoptimuman Parameter Pangkalan Data:

  MySQL ialah aplikasi intensif IO, dan tanggungjawab utamanya ialah pengurusan dan penyimpanan data. Dan kita tahu bahawa masa untuk membaca pangkalan data dari ingatan adalah pada tahap mikrosaat, manakala masa untuk membaca IO dari cakera keras biasa adalah pada tahap milisaat Perbezaan antara keduanya ialah 3 pesanan magnitud. Oleh itu, untuk mengoptimumkan pangkalan data, langkah pertama untuk mengoptimumkan ialah IO, dan menukar cakera IO ke dalam memori IO sebanyak mungkin. Oleh itu, apabila mengoptimumkan parameter pangkalan data MySQL, kami terutamanya mengoptimumkan parameter yang mengurangkan IO cakera: contohnya, gunakan query_cache_size untuk melaraskan saiz cache pertanyaan, dan gunakan innodb_buffer_pool_size untuk melaraskan saiz penimbal

  9. Pelan pelaksanaan explain:

  Pelan pelaksanaan ialah pertanyaan yang dibuat daripada pepohon sintaks abstrak dan maklumat statistik jadual berkaitan yang diperolehi oleh pernyataan SQL selepas lulus melalui penganalisis pertanyaan, Penyelesaian ini dianalisis dan dijana secara automatik oleh pengoptimum pertanyaan. Oleh kerana ia adalah hasil daripada persampelan data dinamik dan analisis statistik, mungkin terdapat ralat analisis, iaitu, mungkin terdapat situasi di mana pelan pelaksanaan tidak optimum. Gunakan kata kunci explain untuk mengetahui cara MySQL melaksanakan penyataan pertanyaan SQL, menganalisis kesesakan prestasi penyataan terpilih dan memperbaik pertanyaan kami. 🎜> Yang penting ialah id, type, key, key_len, rows, extra:

  (1) id: Lajur id boleh difahami sebagai pengecam perintah pelaksanaan SQL. Terdapat beberapa id seperti di sana adalah beberapa pilihan.

  Nilai id yang berbeza: semakin besar nilai id, semakin tinggi keutamaan dan akan dilaksanakan terlebih dahulu;
  Lajur id adalah batal: menunjukkan bahawa ini adalah set hasil dan tidak perlu menggunakannya untuk membuat pertanyaan.

  • (2) select_type: Jenis pertanyaan, terutamanya digunakan untuk membezakan pertanyaan kompleks seperti pertanyaan biasa, pertanyaan bersama, subkueri, dsb.
  • (3) jadual: perwakilan Terangkan jadual mana satu baris sedang mengakses
  • (4) jenis: jenis akses, iaitu, MySQL memutuskan cara mencari baris dalam jadual. Dari yang terbaik ke yang paling teruk: sistem > eq_ref > indexes Kecuali untuk index_merge, jenis lain hanya boleh menggunakan satu indeks. Secara amnya, jenis dikehendaki berada pada tahap rujukan, dan carian julat perlu mencapai tahap julat.

  sistem: Terdapat hanya satu padanan data dalam jadual (sama dengan jadual sistem), yang boleh dianggap sebagai kes khas jenis const
  const: Ia ditemui melalui indeks sekali, menunjukkan penggunaan Indeks kunci utama atau indeks unik
  eq_ref: Medan dalam kunci utama atau indeks unik digunakan untuk sambungan, dan hanya satu baris data yang sepadan akan dikembalikan

  ref: Imbasan indeks biasa, boleh mengembalikan berbilang baris keadaan pertanyaan data yang sepadan.
  • teks penuh: pengambilan indeks teks penuh, indeks teks penuh mempunyai keutamaan yang tinggi Jika indeks teks penuh dan indeks biasa wujud pada masa yang sama, mysql akan memberi keutamaan kepada indeks teks penuh. tanpa mengira kos.
  • ref_or_null: Serupa dengan kaedah ref, kecuali perbandingan nilai nol ditambah.
  • index_merge: Menunjukkan bahawa pertanyaan menggunakan lebih daripada dua indeks, kaedah pengoptimuman penggabungan indeks, dan akhirnya mengambil persimpangan atau kesatuan biasa dan dan atau keadaan menggunakan indeks yang berbeza.
  • unique_subquery: digunakan untuk subquery dalam bentuk di mana, subquery mengembalikan nilai unik tanpa nilai pendua; Subkueri mungkin mengembalikan nilai pendua, dan indeks boleh digunakan untuk menyahduplikasi subkueri.
  • julat: Imbasan julat indeks, biasanya digunakan dalam pertanyaan menggunakan operator seperti >, <, antara, dalam, suka, dsb.
  • indeks: imbasan jadual penuh indeks, imbas pepohon indeks dari awal hingga akhir;
  • semua: lintasi seluruh jadual untuk mencari baris yang sepadan (Walaupun Indeks dan SEMUA kedua-duanya membaca keseluruhan jadual, indeks dibaca daripada indeks, manakala SEMUA dibaca daripada cakera keras)
  • NULL: MySQL menguraikan pernyataan semasa proses pengoptimuman, malah tidak perlu mengakses jadual atau indeks semasa pelaksanaan
  • (5) possible_keys: Indeks yang boleh digunakan dalam pertanyaan
  • (6) kunci: Indeks yang manakah sebenarnya digunakan untuk mengoptimumkan akses kepada jadual
  • (7) key_len: Sebenarnya digunakan Panjang indeks untuk mengoptimumkan pertanyaan, iaitu bilangan bait yang digunakan dalam indeks. Melalui nilai ini, anda boleh mengira medan indeks yang sebenarnya digunakan dalam indeks berbilang lajur.
  • (8) ruj: Menunjukkan medan atau pemalar yang digunakan bersama-sama dengan kekunci

  (9) baris: Berdasarkan statistik jadual dan pemilihan indeks, anggaran secara kasar bilangan bacaan yang perlu baca dengan pertanyaan di sini Bilangan baris, bukan nilai yang tepat.
  (10) tambahan: beberapa maklumat tambahan lain
  menggunakan indeks: menggunakan indeks penutup
  menggunakan keadaan indeks: lajur yang ditanya tidak diindeks Liputan , di mana keadaan penapis menggunakan indeks
  menggunakan sementara: Gunakan jadual sementara untuk menyimpan hasil perantaraan, selalunya digunakan dalam kumpulan mengikut dan susunan mengikut operasi, biasanya kerana tiada indeks pada kumpulan mengikut lajur, ia juga mungkin kerana pada masa yang sama Terdapat kumpulan mengikut dan susunan mengikut, tetapi lajur kumpulan mengikut dan susunan mengikut adalah berbeza Secara umumnya, ini bermakna pertanyaan perlu dioptimumkan
  menggunakan failsort: MySQL mempunyai dua cara untuk. mengisih hasil pertanyaan, satu ialah menggunakan indeks, dan satu lagi adalah jenis fail (isihan luaran berdasarkan isihan cepat, dengan prestasi yang lemah Apabila jumlah data adalah besar, ini akan menjadi proses intensif CPU, jadi). pengisihan boleh dioptimumkan dengan mewujudkan indeks yang sesuai

  • Pembaca yang berminat untuk menerangkan butiran pelan pelaksanaan boleh membaca artikel ini: https://blog.csdn.net/a745233700/article. /details/84335453

  • 10. replikasi master-slave MySQL:

    10.1 Prinsip replikasi master-slave MySQL:

    Slave memperoleh fail log binari binlog daripada Master, kemudian menghuraikan fail log ke dalam pernyataan SQL yang sepadan dan melaksanakan semula operasi pelayan induk pada pelayan hamba Dengan cara ini, ketekalan data dipastikan. Memandangkan proses replikasi tuan-hamba tidak segerak, data antara Hamba dan Tuan mungkin ditangguhkan, dan hanya konsistensi akhir data boleh dijamin. Keseluruhan proses replikasi antara tuan dan hamba diselesaikan terutamanya oleh tiga utas:

    • (1) Benang SQL Hamba: dicipta untuk membaca Log geganti log geganti dan melaksanakan kemas kini yang terkandung dalam log, terletak di sebelah hamba
    • (2) Benang I/O hamba: Baca kandungan yang dihantar oleh pelayan induk Binlog Dump benang dan simpan ke log geganti log geganti pelayan hamba , terletak di bahagian hamba:
    • (3) Benang pembuangan binlog (juga dipanggil benang IO): Hantar kandungan dalam log binari bin-log ke pelayan hamba, terletak di bahagian induk

    Nota: Jika pelayan induk dilengkapi dengan dua pelayan hamba, akan ada dua utas pembuangan Binlog pada pelayan induk, dan setiap pelayan hamba akan mempunyai dua utas

    10.2. Proses replikasi Master-slave:

    • (1) Selepas pelayan induk melaksanakan pernyataan SQL, ia direkodkan dalam fail binari binlog; 🎜>
    (2) Benang IO pada bahagian hamba bersambung ke bahagian induk dan meminta kandungan log seterusnya untuk disalin daripada kedudukan nod pos yang ditentukan bagi fail log bin yang ditentukan (atau dari awal lagi log).
    • (3) Selepas menerima permintaan benang IO dari bahagian hamba, bahagian induk memberitahu benang IO yang bertanggungjawab untuk proses replikasi, dan membaca log binlog yang ditentukan selepas kedudukan nod pos yang ditentukan mengikut maklumat permintaan daripada benang IO bahagian hamba Maklumat log kemudiannya dikembalikan ke benang IO di bahagian hamba. Sebagai tambahan kepada maklumat yang terkandung dalam log binlog, maklumat yang dikembalikan juga termasuk nama fail binlog maklumat yang dikembalikan pada bahagian induk dan kedudukan nod POS dalam log binlog.
    • (4) Selepas menerima maklumat yang dikembalikan oleh IO bahagian induk, benang IO pada bahagian hamba menulis kandungan log binlog yang diterima ke hujung fail log geganti pada bahagian hamba secara bergilir-gilir, dan membaca Nama fail binlog dan lokasi nod pos di bahagian induk direkodkan dalam fail maklumat induk (fail ini disimpan di bahagian hamba), supaya induk boleh diberitahu dari kedudukan mana untuk memulakan penyegerakan data semasa seterusnya penyegerakan;
    • (5) hamba Selepas benang SQL di bahagian induk mengesan kandungan baharu dalam fail log geganti, ia segera menghuraikan kandungan dalam fail log geganti, dan kemudian memulihkannya kepada penyataan SQL sebenarnya dilaksanakan pada bahagian induk, dan kemudian melaksanakan penyataan SQL ini untuk mencapai konsistensi Data antara induk dan hamba;

    (1) Pengasingan baca dan tulis meningkatkan prestasi pangkalan data dengan menambahkan pelayan hamba secara dinamik, melaksanakan penulisan dan kemas kini pada pelayan induk dan melaksanakan fungsi baca pada pelayan hamba.

    (2) Tingkatkan keselamatan data, kerana data telah disalin ke pelayan hamba, dan pelayan hamba boleh menamatkan proses replikasi, jadi ia boleh disandarkan pada pelayan hamba tanpa memusnahkan data yang sepadan pelayan induk.

    (3) Hasilkan data masa nyata pada pelayan induk, dan analisa data ini pada pelayan hamba, dengan itu meningkatkan prestasi pelayan induk.

    • 10.4 Jenis replikasi yang disokong oleh MySQL dan kelebihan dan kekurangannya:
    • Fail log binlog mempunyai dua format, satu ialah Penyata-. Berasaskan (replikasi berasaskan penyata), dan satu lagi ialah Berasaskan Baris (replikasi berasaskan baris). Format lalai ialah Berasaskan Penyata Jika anda ingin menukar format, gunakan pilihan -binlog-format apabila memulakan perkhidmatan Arahan khusus adalah seperti berikut:

    mysqld_safe –user=msyql –. binlog-format=format&

    (1) Replikasi Berasaskan Pernyataan: Pernyataan SQL yang dilaksanakan pada pelayan induk dan pernyataan yang sama dilaksanakan pada pelayan hamba. Kecekapan agak tinggi. Sebaik sahaja didapati bahawa penyalinan tepat tidak boleh dilakukan, penyalinan berasaskan baris akan dipilih secara automatik.

    Kelebihan:

    ① Oleh kerana kenyataan SQL yang direkodkan, ia menggunakan lebih sedikit ruang storan. Log binlog mengandungi peristiwa yang menerangkan operasi pangkalan data, tetapi peristiwa ini hanya termasuk operasi yang menukar pangkalan data, seperti memasukkan, mengemas kini, mencipta, memadam dan operasi lain. Sebaliknya, operasi serupa seperti pilih dan desc tidak akan direkodkan.
    ② Fail log binlog merekodkan semua pernyataan yang mengubah pangkalan data, jadi fail ini boleh digunakan sebagai asas untuk mengaudit pangkalan data.

    Kelemahan:

    • ① Tidak selamat, tidak semua kenyataan yang menukar data akan direkodkan. Tingkah laku bukan deterministik tidak akan direkodkan. Sebagai contoh: untuk memadam atau mengemas kini kenyataan, jika had digunakan tetapi tidak ada susunan mengikut, ini adalah pernyataan tidak pasti dan tidak akan direkodkan.
    • ② Untuk kemas kini, masukkan...pilih pernyataan tanpa syarat indeks, lebih banyak data mesti dikunci, yang mengurangkan prestasi pangkalan data.

    (2) Berasaskan Baris: Salin kandungan yang diubah dan bukannya melaksanakan arahan pada pelayan hamba Disokong bermula dari mysql5.0; :

    ① Semua perubahan akan disalin, yang merupakan cara paling selamat untuk menyalin

    ② Untuk kemas kini, masukkan...pilih Penyata menunggu mengunci lebih sedikit baris; 🎜>
    • Kelemahan:
    • ① Anda tidak boleh menyemak pernyataan yang dilaksanakan melalui fail log binlog, dan anda tidak mempunyai cara untuk mengetahui apa yang diterima pada penyata pelayan, kami hanya boleh lihat data yang telah berubah.

    ② Kerana ia merekodkan data, ruang storan yang diduduki oleh fail log binlog adalah lebih besar daripada yang berasaskan Penyata.

    ③ Operasi dengan jumlah data yang besar akan mengambil masa yang lebih lama.
    • (3) Replikasi jenis campuran: Replikasi berasaskan pernyataan diterima pakai secara lalai Setelah didapati replikasi berasaskan pernyataan tidak boleh tepat, replikasi berasaskan baris akan diterima pakai.
    • Untuk butiran lanjut tentang replikasi tuan-hamba, sila baca artikel ini: https://blog.csdn.net/a745233700/article/details/85256818

    11. Baca Tulis pemisahan:

    11.1. Prinsip pelaksanaan:

    Pengasingan baca dan tulis menyelesaikan masalah bahawa operasi tulis pangkalan data menjejaskan kecekapan pertanyaan. Sesuai untuk senario yang membaca lebih hebat daripada menulis. Asas untuk merealisasikan pemisahan baca-tulis adalah replikasi master-slave Pangkalan data induk menggunakan replikasi master-slave untuk menyegerakkan perubahan datanya sendiri kepada kluster pangkalan data hamba Kemudian pangkalan data induk bertanggungjawab untuk memproses operasi tulis (tentu saja, ia boleh juga melakukan operasi baca), dan pangkalan data hamba bertanggungjawab untuk memproses operasi bacaan, operasi tulis tidak boleh dilakukan. Dan mengikut situasi tekanan, pelbagai pangkalan data hamba boleh digunakan untuk meningkatkan kelajuan operasi membaca, mengurangkan tekanan pada pangkalan data utama, dan meningkatkan prestasi keseluruhan sistem.

    11.2 Sebab pemisahan baca-tulis meningkatkan prestasi:

    (1) Tambah pelayan fizikal dan perkongsian muat; (2) Tuan dan hamba hanya bertanggungjawab untuk menulis dan membaca mereka sendiri, yang sangat mengurangkan perbalahan kunci X dan kunci S

    (3) Pangkalan data hamba boleh dikonfigurasikan dengan enjin MyISAM untuk meningkatkan prestasi pertanyaan dan menjimatkan wang Sistem overhed; dengan melaraskan pangkalan data hamba yang lain.

    • 11.3. Pelaksanaan membaca dan menulis Mysql:

    (1) Pelaksanaan dalaman berdasarkan kod program: Dalam kod, klasifikasi penghalaan dilakukan berdasarkan pilih dan masukkan. Kelebihannya ialah prestasinya lebih baik, kerana program ini dilaksanakan dalam kod dan tidak memerlukan perbelanjaan perkakasan tambahan Kelemahannya ialah ia memerlukan pemaju untuk melaksanakannya, dan kakitangan operasi dan penyelenggaraan tidak mempunyai cara untuk memulakan.

    (2) Pelaksanaan berdasarkan lapisan proksi perantaraan: Proksi biasanya antara pelayan aplikasi dan pelayan pangkalan data Selepas menerima permintaan daripada pelayan aplikasi, pelayan pangkalan data proksi memajukannya ke bahagian belakang pangkalan data berdasarkan pertimbangan Berikut adalah lapisan agen perwakilan.

    12. Sub-pangkalan data dan sub-jadual: sub-jadual menegak, sub-pangkalan data menegak, sub-jadual mendatar, sub-pangkalan data mendatar
    • Pengasingan Baca Tulis menyelesaikan tekanan operasi baca dan tulis pangkalan data, tetapi tidak menyuraikan tekanan storan pangkalan data Menggunakan sub-pangkalan data dan sub-jadual boleh menyelesaikan kesesakan storan pangkalan data dan menambah baik pertanyaan kecekapan pangkalan data.

    12.1. Pembahagian menegak:

    (1) Pembahagian jadual menegak: Bahagikan jadual kepada berbilang jadual mengikut medan, dan setiap jadual menyimpan sebahagian daripada padang itu. Secara amnya, medan yang biasa digunakan akan diletakkan dalam satu jadual, dan medan yang kurang biasa digunakan akan diletakkan dalam jadual lain.

    Kelebihan:
    (1) Mengelakkan persaingan IO mengurangkan kebarangkalian mengunci meja. Oleh kerana medan besar kurang cekap, pertama, medan besar mengambil lebih banyak ruang, dan bilangan baris yang disimpan dalam satu halaman dikurangkan, yang akan meningkatkan operasi IO kedua, jumlah data adalah besar, dan ia mengambil masa yang lama untuk membaca.

    (2) boleh meningkatkan kecekapan pertanyaan data popular dengan lebih baik.

    • (2) Pemisahan pangkalan data menegak: Pisahkan jadual kepada pangkalan data yang berbeza mengikut modul perniagaan yang berbeza, sesuai untuk gandingan yang sangat rendah antara perniagaan dan sistem yang jelas logik perniagaan.

    • Kelebihan:

    Kurangkan gandingan dalam perniagaan dan memudahkan pengurusan hierarki perniagaan yang berbeza

    Boleh meningkatkan bilangan sambungan IO dan pangkalan data serta menyelesaikannya masalah mesin tunggal Masalah bottleneck sumber storan perkakasan

    (3) Kelemahan pemisahan menegak (sub-perpustakaan, sub-jadual):

    • Lewahan kunci utama , perlu mengurus lajur berlebihan

    Pemprosesan transaksi menjadi rumit

    Masih terdapat masalah volum data yang berlebihan dalam satu jadual

    • 12.2 , Pembahagian mendatar:

    • (1) Pemisahan jadual mendatar: Dalam pangkalan data yang sama, bahagikan data jadual yang sama kepada berbilang jadual mengikut peraturan tertentu.

      Kelebihan:

      • Selesaikan masalah volum data yang berlebihan dalam satu jadual
      • Elakkan persaingan IO dan kurangkan kebarangkalian kunci meja

      (2) Pemisahan pangkalan data mendatar: Pisahkan data jadual yang sama kepada pangkalan data berbeza mengikut peraturan tertentu, dan pangkalan data berbeza boleh diletakkan pada pelayan berbeza.

      Kelebihan:

      • Selesaikan masalah kesesakan volum data yang besar dalam satu pangkalan data
      • Mengurangkan konflik IO, mengurangkan persaingan kunci dan masalah dengan pangkalan data tertentu Tidak menjejaskan pangkalan data lain dan meningkatkan kestabilan dan ketersediaan sistem

      (3) Kelemahan pemisahan mendatar (sub-jadual, sub-pangkalan data):

      • Konsistensi urus niaga yang dipecahkan sukar diselesaikan
      • Prestasi SAMBUTAN silang nod adalah lemah dan logiknya akan menjadi rumit
      • Peluasan data sukar dan sukar dikekalkan

      12.3 Penyelesaian kepada masalah yang wujud dalam sub-pangkalan data dan jadual:

      (1) Masalah transaksi:

      ① Penyelesaian 1: Gunakan transaksi teragih :

      Kelebihan: Diuruskan oleh pangkalan data, mudah dan berkesan.
      • Kelemahan: Kos prestasi tinggi, terutamanya kerana semakin banyak serpihan.

      ② Pilihan 2: Program dan pangkalan data bersama-sama mengawal pelaksanaan Prinsipnya adalah untuk menguraikan transaksi yang diedarkan merentasi berbilang pangkalan data kepada berbilang transaksi kecil yang hanya wujud pada satu pangkalan data dan menyerahkannya kepada aplikasi. Program untuk mengawal keseluruhan setiap transaksi kecil.

      Kelebihan: Kelebihan dalam prestasi;
      • Kelemahan: Kawalan urus niaga yang fleksibel diperlukan dalam aplikasi. Jika anda menggunakan pengurusan transaksi spring, anda akan menghadapi kesukaran tertentu dalam membuat perubahan.

      (2) Masalah sambung silang nod:

      Cara biasa untuk menyelesaikan masalah ini ialah dengan menanyakan pelaksanaan dalam dua kali: dalam kali pertama Hasil pertanyaan menumpukan pada mencari ID data yang berkaitan dan memulakan permintaan kedua berdasarkan ID ini untuk mendapatkan data yang berkaitan.

      (3) Kiraan silang nod, susunan mengikut, kumpulan mengikut, halaman dan isu fungsi agregat:

      Oleh kerana jenis masalah ini memerlukan pengiraan berdasarkan keseluruhan data ditetapkan. Kebanyakan ejen tidak akan mengendalikan kerja penggabungan secara automatik. Penyelesaian adalah serupa dengan menyelesaikan masalah cantuman nod silang Hasilnya diperoleh pada setiap nod dan kemudian digabungkan pada bahagian aplikasi. Berbeza daripada join, pertanyaan setiap nod boleh dilaksanakan secara selari, jadi kelajuannya jauh lebih pantas daripada satu jadual besar. Tetapi jika set keputusan adalah besar, penggunaan memori aplikasi menjadi masalah.

      12.4. Selepas pangkalan data dibahagikan kepada jadual, bagaimana untuk berurusan dengan kunci ID?

      Selepas pangkalan data dibahagikan kepada jadual, ID setiap jadual tidak boleh bermula dari 1, jadi ID global diperlukan terutamanya kaedah berikut untuk menetapkan ID global:

      (1) UUID:

      Kelebihan: ID yang dijana secara tempatan, tidak memerlukan panggilan jauh, unik di peringkat global dan tidak berulang.
      • Kelemahan: Ia mengambil banyak ruang dan tidak sesuai untuk pengindeksan.

      (2) ID kenaikan automatik pangkalan data: Gunakan ID kenaikan automatik pangkalan data selepas membahagikan pangkalan data ke dalam jadual Sebuah perpustakaan yang khusus digunakan untuk menjana kunci utama diperlukan setiap kali perkhidmatan menerima permintaan , ia mula-mula meminta ini Masukkan sekeping data tidak bermakna ke dalam pangkalan data, dapatkan ID yang ditambah secara automatik oleh pangkalan data, dan gunakan ID ini untuk menulis data dalam pangkalan data dan jadual yang berasingan.

      Kelebihan: Mudah dan mudah dilaksanakan.
      • Kelemahan: Terdapat kesesakan di bawah konkurensi yang tinggi.

      (3) ID janaan Redis:

      Kelebihan: Tidak bergantung pada pangkalan data dan mempunyai prestasi yang lebih baik.
      • Kelemahan: Pengenalan komponen baharu akan meningkatkan kerumitan sistem

      (4) Algoritma kepingan salji Twitter: Ia ialah ID panjang 64-bit, 1 bit daripadanya adalah tidak digunakan, 41 bit digunakan sebagai milisaat, 10 bit digunakan sebagai ID mesin yang berfungsi, dan 12 bit digunakan sebagai nombor siri.

      1bit: Bit pertama lalai kepada 0, kerana jika bit pertama dalam binari ialah 1, ia adalah nombor negatif, tetapi ID tidak boleh negatif.
      • 41bit: Mewakili Setem masa, unit ialah milisaat.
      • 10bit: Rekod ID mesin yang berfungsi, yang mana 5 bit mewakili ID bilik komputer dan 5 bit mewakili ID mesin.
      • 12bit: digunakan untuk merekodkan ID berbeza yang dijana dalam milisaat yang sama.

      (5) Sistem penjanaan ID teragih Meituan’s Leaf, sistem penjanaan ID teragih Meituan-Dianping:

      13 🎜> Pemisahan adalah untuk menyimpan data jadual di kawasan yang berbeza mengikut peraturan tertentu, iaitu, untuk membahagikan fail data jadual ke dalam beberapa blok kecil. , dan kemudian bertanya terus dalam kawasan yang sepadan Tidak perlu menanyakan semua data jadual, yang meningkatkan prestasi pertanyaan. Pada masa yang sama, jika data jadual sangat besar dan tidak boleh dimuatkan pada satu cakera, kami juga boleh memperuntukkan data kepada cakera yang berbeza untuk menyelesaikan masalah kesesakan penyimpanan Menggunakan berbilang cakera juga boleh meningkatkan kecekapan IO cakera dan menambah baik prestasi pangkalan data. Apabila menggunakan jadual partition, anda perlu ambil perhatian bahawa medan partition mesti diletakkan dalam kunci utama atau indeks unik, dan bilangan maksimum partition untuk setiap jadual ialah 1024 jenis partition biasa ialah: Range partition, List partition , Pembahagian cincang, Pembahagian kunci,

      • (1) Pembahagian julat: partition mengikut julat sela berterusan
      • (2) Pembahagian senarai: pilih pembahagian mengikut nilai dalam set yang diberikan.
      • (3) Pembahagian cincang: Pembahagian berdasarkan nilai pulangan ungkapan yang ditentukan pengguna yang dikira menggunakan nilai lajur baris ini yang akan dimasukkan ke dalam jadual. Fungsi ini boleh mengandungi sebarang ungkapan yang sah dalam MySQL yang menghasilkan nilai integer bukan negatif.
      • (4) Pembahagian kunci: sama dengan pembahagian HASH, perbezaannya ialah pembahagian kunci hanya menyokong pengiraan satu atau lebih lajur, dan fungsi cincang pembahagian kunci disediakan oleh pelayan MySQL.

      (1) Kelebihan pembahagian jadual:

      ① Kebolehskalaan:

      • Pembahagian pada berbeza cakera boleh menyelesaikan masalah kesesakan kapasiti cakera tunggal, menyimpan lebih banyak data, dan juga menyelesaikan masalah kesesakan IO cakera tunggal.

      ② Tingkatkan prestasi pangkalan data:

      • Kurangkan jumlah data yang perlu dilalui semasa mendapatkan semula pangkalan data Apabila membuat pertanyaan, anda hanya perlu menanyakan partition yang sepadan dengan data.
      • Elakkan sekatan akses yang saling eksklusif bagi indeks tunggal Innodb
      • Untuk fungsi agregat, seperti sum() dan count(), pemprosesan selari boleh dilakukan dalam setiap partition, dan pada akhirnya hanya semua partition perlu dikira Keputusan yang diperoleh

      ③ adalah mudah untuk pengendalian data dan pengurusan penyelenggaraan:

      • adalah mudah untuk pengurusan pemeliharaan, pemadaman pantas boleh dicapai dengan memadamkan kesan sekatan. Contohnya, untuk memadamkan data sejarah pada masa tertentu, laksanakan secara langsung truncate, atau secara langsung menjatuhkan keseluruhan partition, yang lebih cekap daripada memadam;
      • Dalam sesetengah senario, sandaran dan pemulihan jadual partition tunggal akan menjadi lebih cekap.

      14 Adakah ID penambahan automatik atau UUID biasanya digunakan sebagai kunci utama?

      (1) ID kenaikan automatik:

      Kelebihan menggunakan ID kenaikan automatik:

      • Panjang medan akan menjadi lebih kecil daripada UUID.
      • Pangkalan data dinomborkan secara automatik dan disimpan mengikut tertib, yang memudahkan untuk mendapatkan semula
      • Tidak perlu risau tentang pertindihan kunci primer

      Keburukan menggunakan kekunci sendiri meningkatkan ID:

      • Oleh kerana ia meningkat sendiri, dalam senario perniagaan tertentu, mudah bagi orang lain untuk menyemak jumlah perniagaan.
      • Ia akan menjadi sangat menyusahkan apabila pemindahan data atau penggabungan jadual berlaku
      • Dalam senario konkurensi yang tinggi, persaingan untuk penguncian yang meningkat sendiri akan mengurangkan daya pemprosesan pangkalan data

      (2) UUID: Kod pengenalan unik universal dikira dan dijana berdasarkan data seperti masa semasa, kaunter dan pengenalan perkakasan.

      Kelebihan menggunakan UUID:

      • Pengenalan unik, tiada isu pertindihan perlu dipertimbangkan dan keunikan global boleh dicapai apabila data dipecah dan digabungkan.
      • boleh dijana pada lapisan aplikasi untuk meningkatkan daya pemprosesan pangkalan data.
      • Tidak perlu risau tentang kebocoran volum perniagaan.

      Kelemahan penggunaan UUID:

      • Oleh kerana UUID dijana secara rawak, IO rawak akan berlaku, menjejaskan kelajuan pemasukan, dan menyebabkan penggunaan cakera keras yang rendah.
      • UUID mengambil banyak ruang, dan lebih banyak indeks dicipta, lebih besar impaknya.
      • Membandingkan saiz antara UUID adalah lebih perlahan daripada ID yang meningkat sendiri, yang menjejaskan kelajuan pertanyaan.

      Dalam keadaan biasa, MySQL mengesyorkan menggunakan ID kenaikan automatik, kerana dalam enjin storan InnoDB MySQL, indeks kunci utama ialah indeks berkelompok, dan indeks kunci utama ialah nod daun pokok B Nilai kunci utama dan data disimpan mengikut urutan Jika indeks kunci utama ialah ID peningkatan automatik, ia hanya perlu disusun mengikut urutan dihasilkan, yang akan menyebabkan sejumlah besar pergerakan data semasa memasukkan data, mengakibatkan Sebilangan besar pemecahan memori menyebabkan penurunan dalam prestasi pemasukan.

      15 Paparan:

      Paparan ialah jadual yang diperoleh daripada satu atau lebih jadual (atau paparan), dan kandungannya ditakrifkan oleh suatu pertanyaan. Paparan ialah jadual maya Hanya definisi paparan disimpan dalam pangkalan data, dan data yang sepadan dengan paparan tidak disimpan Apabila mengendalikan data paparan, sistem mengendalikan jadual asas yang sepadan mengikut definisi pandangan. Boleh dikatakan pandangan ialah jadual yang dibina di atas jadual asas Struktur dan kandungannya berasal dari jadual asas dan wujud berdasarkan kewujudan jadual asas. Paparan boleh sepadan dengan satu jadual asas atau berbilang jadual asas. Pandangan ialah abstraksi jadual asas dan perhubungan baharu yang diwujudkan dalam erti kata yang logik.

      (1) Kelebihan paparan:

      • memudahkan operasi dan mentakrifkan data yang kerap digunakan sebagai paparan
      • Keselamatan, pengguna hanya boleh bertanya dan mengubah suai data yang boleh dilihat
      • Kebebasan logik, melindungi kesan struktur jadual sebenar

      (2) Kelemahan pandangan:

      • Lemah prestasi, pangkalan data mesti menukar pertanyaan pandangan menjadi pertanyaan jadual asas Jika paparan ditakrifkan oleh pertanyaan berbilang jadual yang kompleks, maka pertanyaan ringkas pandangan mesti diproses oleh pangkalan data kombinasi kompleks yang memerlukan masa.

      16. Prosedur tersimpan Prosedur:

      Penyata SQL perlu disusun dahulu dan kemudian dilaksanakan, dan prosedur tersimpan ialah set prosedur yang direka untuk melengkapkan tertentu Set pernyataan SQL berfungsi disusun dan disimpan dalam pangkalan data Pengguna memanggilnya dengan menyatakan nama prosedur yang disimpan dan memberikan parameter.

      Anda juga boleh menggunakan atur cara untuk melaksanakan logik kompleks untuk mengendalikan pangkalan data, jadi mengapa anda memerlukan prosedur tersimpan? Sebab utama ialah kecekapan menggunakan program untuk memanggil API adalah agak perlahan. Aplikasi perlu menyerahkan penyata SQL kepada enjin MYSQL melalui enjin untuk melaksanakannya paling mahir dan mampu menyelesaikannya.

      Kelebihan prosedur tersimpan:

      • (1) Pengaturcaraan komponen standard: Selepas prosedur tersimpan dibuat, ia boleh dipanggil beberapa kali dalam atur cara tanpa perlu menulis semula prosedur. pernyataan SQL untuk prosedur tersimpan. Dan DBA boleh mengubah suai prosedur yang disimpan pada bila-bila masa tanpa sebarang kesan pada kod sumber aplikasi.
      • (2) Kelajuan pelaksanaan yang lebih pantas: Jika operasi mengandungi sejumlah besar kod Transaksi-SQL atau dilaksanakan berbilang kali, prosedur yang disimpan akan dilaksanakan lebih cepat daripada pemprosesan kelompok. Oleh kerana prosedur tersimpan disusun terlebih dahulu, apabila anda menjalankan prosedur tersimpan buat kali pertama, pengoptimum menganalisis dan mengoptimumkan pertanyaan dan memberikan pelan pelaksanaan yang akhirnya disimpan dalam jadual sistem. Penyataan Transaction-SQL kelompok mesti disusun dan dioptimumkan setiap kali ia dijalankan, dan kelajuannya agak perlahan.
      • (3) Tingkatkan kefungsian dan fleksibiliti bahasa SQL: Prosedur tersimpan boleh ditulis menggunakan penyataan kawalan, sangat fleksibel dan boleh melengkapkan pertimbangan yang kompleks dan operasi yang kompleks.
      • (4) Kurangkan trafik rangkaian: Untuk operasi pada objek pangkalan data yang sama (seperti pertanyaan, pengubahsuaian), jika pernyataan Transaksi-SQL yang terlibat dalam operasi ini disusun ke dalam prosedur tersimpan, maka apabila operasi dilakukan pada komputer klien Apabila prosedur tersimpan dipanggil, hanya pernyataan panggilan dihantar melalui rangkaian, sekali gus mengurangkan trafik rangkaian dan mengurangkan beban rangkaian.
      • (5) Gunakan sepenuhnya ia sebagai mekanisme keselamatan: Dengan mengehadkan kebenaran untuk melaksanakan proses tersimpan tertentu, adalah mungkin untuk mengehadkan kebenaran akses data yang sepadan dan mengelakkan pengguna yang tidak dibenarkan daripada mengakses data. . Akses memastikan keselamatan data.

      17. Pencetus:

      Pencetus ialah objek pangkalan data yang berkaitan dengan jadual apabila pencetus muncul pada jadual di mana pencetus terletak, Apabila peristiwa ditentukan dan syarat yang ditentukan dipenuhi, set pernyataan yang ditakrifkan dalam pencetus akan dilaksanakan. Ciri pencetus boleh digunakan pada bahagian pangkalan data untuk memastikan integriti data. Pencetus ialah prosedur tersimpan khas Perbezaannya ialah prosedur tersimpan perlu dipanggil menggunakan panggilan, manakala pencetus tidak memerlukan panggilan atau panggilan manual keupayaan kawalan data yang lebih canggih dan kompleks daripada fungsi standard pangkalan data itu sendiri.
      

      18. Kursor:

      Kursor ialah pengenalan berenang dan boleh bertindak sebagai penunjuk arah pangkalan data pertanyaan dan kembalikan Semua rekod dalam set hasil, tetapi hanya satu rekod boleh diekstrak pada satu masa, iaitu, hanya satu baris data boleh ditunjuk dan diambil pada satu masa untuk melaksanakan operasi yang sepadan. Apabila anda tidak menggunakan kursor, ia bersamaan dengan seseorang yang memberikan anda segala-galanya sekaligus dan membiarkan anda mengambilnya selepas menggunakan kursor, ia bersamaan dengan seseorang yang memberikannya kepada anda satu demi satu, anda boleh tengok dulu benda ni sama ada bagus atau tidak, anda buat pilihan anda sendiri.

      Pembelajaran yang disyorkan: tutorial video mysql

Atas ialah kandungan terperinci Ringkaskan dan susun soalan temu bual biasa tentang pangkalan data MySQL. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!