Apakah isu asas dengan MySQL?

Bab Biasa

1. Beritahu kami tentang tiga paradigma utama pangkalan data?

Bentuk normal pertama: atomicity medan, bentuk normal kedua: baris adalah unik dan mempunyai lajur kunci primer, bentuk normal ketiga: setiap lajur berkaitan dengan lajur kunci primer.

Dalam aplikasi sebenar, sebilangan kecil medan berlebihan akan digunakan untuk mengurangkan bilangan jadual berkaitan dan meningkatkan kecekapan pertanyaan.

2. Hanya satu keping data ditanya, tetapi pelaksanaannya sangat perlahan.

• Pangkalan data MySQL itu sendiri disekat, contohnya: sistem atau sumber rangkaian tidak mencukupi

• Pernyataan SQL disekat, contohnya : Kunci meja, kunci baris, dsb., menyebabkan enjin storan tidak melaksanakan pernyataan SQL yang sepadan

• Ia sememangnya penggunaan indeks yang tidak betul, dan indeks tidak digunakan

• Disebabkan ciri data dalam jadual, indeks dialih keluar, tetapi bilangan pulangan jadual adalah besar

3 . Count(*), count(0), count(id) kaedah pelaksanaan Perbezaannya?

• Untuk fungsi kiraan dalam bentuk count(*), count(常数), count(主键), pengoptimum boleh memilih indeks dengan kos imbasan terkecil untuk melaksanakan pertanyaan, dengan itu meningkatkan kecekapan proses pelaksanaan mereka adalah sama.

• Untuk count(非索引列), pengoptimum memilih imbasan jadual penuh, yang bermaksud ia hanya boleh mengimbas nod daun indeks berkelompok secara berurutan.

• count(二级索引列)Hanya indeks yang mengandungi lajur yang kami tentukan boleh dipilih untuk melaksanakan pertanyaan, yang mungkin menyebabkan kos pelaksanaan indeks yang dipilih oleh pengoptimum bukan yang terkecil.

4.

1) Jika jumlah data agak besar, gunakan sandaran fizikal xtrabackup. Lakukan sandaran penuh pangkalan data secara kerap, dan anda juga boleh melakukan sandaran tambahan.

2) Jika jumlah data adalah kecil, gunakan mysqldump atau mysqldumper, dan kemudian gunakan binlog untuk memulihkan atau menyediakan kaedah master-slave untuk memulihkan data Anda boleh memulihkan daripada perkara berikut:

• Pernyataan salah operasi DML: Anda boleh menggunakan kilas balik untuk menghuraikan acara binlog dahulu dan kemudian membalikkannya.

• Salah operasi penyata DDL: Data hanya boleh dipulihkan melalui sandaran penuh + aplikasi binlog. Apabila jumlah data agak besar, masa pemulihan akan menjadi sangat lama.

• rm Pemadaman: Gunakan sandaran merentas bilik komputer, atau lebih baik merentasi bandar.

5 Perbezaan antara drop, truncate dan delete

• Proses pemadaman dengan pernyataan DELETE ialah memadam. daripada jadual setiap kali Padam baris dan simpan pemadaman baris dalam log sebagai rekod transaksi untuk operasi rollback.

• TRUNCATE TABLE memadam semua data daripada jadual sekaligus dan tidak merekodkan rekod operasi pemadaman individu dalam log tidak boleh dipulihkan. Dan pencetus pemadaman yang berkaitan dengan jadual tidak akan diaktifkan semasa proses pemadaman, dan kelajuan pelaksanaan adalah pantas.

• Pernyataan drop melepaskan semua ruang yang diduduki oleh meja.

6 Mengapa pertanyaan jadual besar MySQL tidak memecahkan memori?

• MySQL adalah "menghantar semasa membaca", yang bermaksud bahawa jika pelanggan menerima perlahan, pelayan MySQL tidak akan dapat menghantar keputusan disebabkan oleh pelaksanaan ini masa menjadi lebih panjang.

• Pelayan tidak perlu menyimpan set hasil lengkap. Proses mendapatkan dan menghantar data semuanya dikendalikan melalui next_buffer.

• Halaman data memori diuruskan dalam Buffer Pool (BP).

• InnoDB mengurus Buffer Pool menggunakan algoritma LRU yang dipertingkatkan, yang dilaksanakan menggunakan senarai terpaut. Dalam pelaksanaan InnoDB, keseluruhan senarai terpaut LRU dibahagikan kepada kawasan muda dan kawasan lama mengikut nisbah 5:3 untuk memastikan data panas tidak akan dihanyutkan apabila data sejuk dimuatkan dalam kelompok besar.

7 Bagaimana untuk menangani paging dalam (paging yang sangat besar)?

• Gunakan pengoptimuman id: first find halaman terakhir ID maksimum, dan kemudian gunakan indeks pada id untuk membuat pertanyaan, sama seperti pilih * daripada pengguna di mana id>1000000 had 100.

• Optimumkan dengan indeks penutup: Apabila pertanyaan MySQL mencecah indeks sepenuhnya, ia dipanggil indeks penutup, yang sangat pantas kerana pertanyaan hanya perlu mencari pada indeks dan boleh dikembalikan terus selepas itu tanpa Kemudian kembali ke jadual untuk mendapatkan data Oleh itu, kita boleh mengetahui terlebih dahulu ID indeks, dan kemudian mendapatkan data berdasarkan Id.

• Hadkan bilangan halaman jika perniagaan membenarkan

8. Bagaimana anda mengoptimumkan SQL dalam pembangunan harian?

• Tambah indeks yang sesuai: indeks medan yang digunakan sebagai syarat pertanyaan dan susunan mengikut, wujudkan indeks gabungan mempertimbangkan berbilang medan pertanyaan dan perhatikan susunan medan indeks gabungan . Letakkan lajur yang paling biasa digunakan sebagai syarat terhad di sebelah kiri, dalam susunan menurun.

• Optimumkan struktur jadual: medan angka lebih baik daripada jenis rentetan, jenis data yang lebih kecil biasanya lebih baik, cuba gunakan NOT NULL

• Pertanyaan pengoptimuman pernyataan: Analisis pelan pelaksanaan SQL, sama ada ia mencapai indeks, dsb. Jika SQL sangat kompleks, optimumkan struktur SQL Jika jumlah data jadual terlalu besar, pertimbangkan untuk membahagikan jadual

9. MySQL Apakah perbezaan antara sambungan serentak dan pertanyaan serentak?

• Dalam hasil melaksanakan senarai proses rancangan, saya melihat beribu-ribu sambungan, yang merujuk kepada sambungan serentak.

• Pernyataan "sedang melaksanakan" ialah pertanyaan serentak.

• Sebilangan besar sambungan serentak menjejaskan memori.

• Pertanyaan serentak yang terlalu tinggi tidak baik untuk CPU. Mesin mempunyai bilangan teras CPU yang terhad dan jika semua utas tergesa-gesa masuk, kos penukaran konteks akan menjadi terlalu tinggi.

• Perlu diambil perhatian bahawa selepas benang memasuki kunci tunggu, kiraan benang serentak dikurangkan satu, jadi benang menunggu kunci baris atau kunci celah tidak termasuk dalam julat pengiraan . Maksudnya, benang yang menunggu kunci tidak memakan CPU, dengan itu menghalang keseluruhan sistem daripada terkunci.

10 Bagaimanakah MySQL beroperasi secara dalaman apabila mengemas kini nilai medan kepada nilai asal?

• Dengan data yang sama, tiada kemas kini akan dilakukan.

• Walau bagaimanapun, kaedah pemprosesan log adalah berbeza untuk format binlog yang berbeza:

• 1) Apabila berdasarkan mod baris, pelayan The lapisan sepadan dengan rekod yang akan dikemas kini dan mendapati bahawa nilai baru adalah konsisten dengan nilai lama ia kembali secara langsung tanpa mengemas kini dan tidak merekodkan binlog.

• 2) Apabila berdasarkan pernyataan atau format campuran, MySQL melaksanakan pernyataan kemas kini dan merekodkan pernyataan kemas kini ke binlog.

11. Apakah perbezaan antara tarikh dan cap waktu?

• Julat tarikh masa tarikh ialah 1001-9999 julat masa cap masa ialah 1970-2038

• masa storan Masa mempunyai; tiada kaitan dengan zon masa; masa storan cap masa adalah berkaitan dengan zon masa, dan nilai yang dipaparkan juga bergantung pada zon masa

• Ruang storan tarikh ialah 8 bait; cap masa ialah 4 bait

• Nilai lalai datetime ialah batal; medan cap masa adalah tidak batal secara lalai dan nilai lalai ialah masa semasa (current_timestamp)

12. Apakah tahap pengasingan urus niaga?

• "Read Uncommitted" ialah tahap paling rendah dan tidak boleh dijamin dalam apa jua keadaan

• "Read Uncommitted" ( Read Committed) dapat mengelakkan berlakunya bacaan kotor

• "Repeatable Read" dapat mengelakkan berlakunya bacaan kotor dan tidak berulang

• "Serializable" boleh mengelakkan berlakunya bacaan kotor, bacaan tidak boleh berulang dan bacaan hantu

• Tahap pengasingan transaksi lalai MySQL ialah "Bacaan Boleh Diulang" )

13. Terdapat dua perintah kill dalam MySQL

• kill query + thread id, yang bermaksud untuk menamatkan Pernyataan ini sedang dilaksanakan dalam thread

• bunuh sambungan + id utas, di sini sambungan boleh lalai, yang bermaksud memutuskan sambungan

Bab Indeks

1 adakah kategori indeks?

• Mengikut kandungan nod daun, jenis indeks dibahagikan kepada indeks kunci utama dan indeks kunci bukan utama.

• Nod daun indeks kunci primer menyimpan keseluruhan baris data. Dalam InnoDB, indeks kunci utama juga dipanggil indeks berkelompok.

• Kandungan nod daun dalam indeks bukan kunci utama ialah nilai kunci utama. Dalam InnoDB, indeks kunci bukan utama juga dipanggil indeks sekunder.

2. Apakah perbezaan antara indeks berkelompok dan indeks tidak berkelompok?

• Indeks berkelompok: Indeks berkelompok ialah indeks yang dibuat dengan kunci utama Indeks berkelompok menyimpan data dalam jadual dalam nod daun.

  

• Indeks bukan berkelompok: Indeks yang dicipta oleh kunci bukan utama dan lajur indeks disimpan dalam nod daun Gunakan indeks tidak berkelompok Apabila indeks berkelompok menanyakan data, dapatkan kunci utama pada daun dan kemudian cari data yang anda ingin cari. (Proses mendapatkan kunci utama dan kemudian mencarinya dipanggil pulangan jadual).

  

• Indeks penutup: Dengan mengandaikan bahawa lajur yang disoal adalah lajur yang sepadan dengan indeks, tidak perlu untuk kembali ke jadual untuk menyemak Kemudian lajur indeks ini dipanggil indeks penutup.

3. Mengapakah InnoDB mereka bentuk pokok B+ dan bukannya B-Tree, Hash, pokok binari dan pokok merah-hitam?

• Indeks cincang boleh mengendalikan penambahan, pemadaman, pengubahsuaian dan pertanyaan baris data tunggal pada kelajuan O(1), tetapi apabila berhadapan dengan pertanyaan julat atau pengisihan, ia akan membawa kepada hasil imbasan jadual penuh.

• B-tree boleh menyimpan data dalam nod bukan daun Memandangkan semua nod mungkin mengandungi data sasaran, kami sentiasa perlu melintasi subpohon ke bawah dari nod akar untuk mencari nod yang memenuhi. baris data, ciri ini membawa sejumlah besar I/O rawak, menyebabkan kemerosotan prestasi.

• Semua baris data pokok B+ disimpan dalam nod daun, dan nod daun ini boleh disambungkan mengikut urutan melalui "penunjuk". di bawah Anda boleh terus melompat antara berbilang nod anak, yang boleh menjimatkan banyak masa I/O cakera.

• Pokok binari: Ketinggian pokok tidak sekata dan tidak boleh mengimbangi sendiri Kecekapan carian adalah berkaitan dengan data (ketinggian pokok), dan kos IO adalah tinggi.

• Pokok merah-hitam: Ketinggian pokok meningkat apabila jumlah data meningkat dan kos IO adalah tinggi.

4. Mari kita bincangkan tentang indeks berkelompok dan indeks tidak berkelompok?

• Dalam InnoDB, nod daun indeks B+ Tree menyimpan keseluruhan baris data ialah indeks kunci utama, juga dipanggil indeks berkelompok, iaitu penyimpanan data dan indeks diletakkan Apabila anda sampai ke sekeping, anda mencari indeks dan anda menemui data.

• Nod daun indeks B+Tree menyimpan nilai kunci primer, yang merupakan indeks kunci bukan primer, juga dipanggil indeks tidak berkelompok dan indeks sekunder.

• Indeks pertama biasanya IO berjujukan, dan operasi kembali ke jadual ialah IO rawak. Lebih banyak kali kita perlu kembali ke jadual, iaitu, lebih banyak kali kita memerlukan IO rawak, lebih banyak kita cenderung menggunakan imbasan jadual penuh.

5. Adakah indeks tidak berkelompok pasti mengembalikan pertanyaan jadual?

• Tidak semestinya ini melibatkan sama ada semua medan yang diperlukan oleh pernyataan pertanyaan mengenai indeks Jika semua medan mencapai indeks, maka tidak perlu melakukan pertanyaan kembali ke meja. Indeks mengandungi (meliputi) nilai semua medan yang perlu ditanya, dan dipanggil "indeks penutup".

6. Beritahu kami tentang prinsip awalan paling kiri MySQL?

• Prinsip awalan paling kiri adalah keutamaan paling kiri Apabila membuat indeks berbilang lajur, mengikut keperluan perniagaan, lajur yang paling kerap digunakan dalam klausa diletakkan di paling kiri. sebelah.

• MySQL akan terus memadankan ke kanan sehingga ia menemui pertanyaan julat (>, <, antara, suka) dan berhenti memadankan, seperti a = 1 dan b = 2 dan c > 3 dan d = 4 Jika anda mencipta indeks dalam susunan (a, b, c, d), indeks d tidak akan digunakan Jika anda mencipta indeks (a, b, d, c ), anda boleh menggunakan kedua-dua a dan b , susunan d boleh dilaraskan sewenang-wenangnya.

• = dan in boleh tidak teratur, seperti a = 1 dan b = 2 dan c = 3. Indeks (a, b, c) boleh dibuat dalam sebarang susunan , dan pengoptimum pertanyaan MySQL akan Membantu anda mengoptimumkannya ke dalam bentuk yang boleh dikenali oleh indeks.

7. Apakah itu index pushdown?

• Apabila prinsip awalan paling kiri dipenuhi, awalan paling kiri boleh digunakan untuk mencari rekod dalam indeks.

• Sebelum MySQL 5.6, anda hanya boleh mengembalikan jadual satu demi satu bermula dari ID. Cari baris data pada indeks kunci utama, dan kemudian bandingkan nilai medan.

• Pengoptimuman tekan bawah indeks (tekan ke bawah keadaan indeks) yang diperkenalkan dalam MySQL 5.6 boleh menilai terlebih dahulu medan yang disertakan dalam indeks semasa proses traversal indeks, dan menapis terus medan yang tidak memenuhi rekod untuk mengurangkan bilangan pulangan jadual.

8 Mengapakah Innodb menggunakan id penambahan automatik sebagai kunci utama?

• Jika jadual menggunakan kunci utama penambahan automatik, maka setiap kali rekod baharu dimasukkan, rekod akan ditambah secara berurutan ke kedudukan nod indeks semasa yang seterusnya . Apabila halaman penuh, Halaman baharu akan dibuka secara automatik. Jika anda menggunakan kunci utama yang tidak meningkat secara automatik (seperti nombor ID atau nombor pelajar, dsb.), memandangkan nilai kunci utama yang dimasukkan setiap kali adalah lebih kurang rawak, setiap rekod baharu mesti dimasukkan di suatu tempat di tengah-tengah halaman indeks yang sedia ada, dengan kerap operasi mengalihkan dan kelui menyebabkan sejumlah besar pemecahan dan mengakibatkan struktur indeks yang tidak cukup padat Selepas itu, OPTIMIZE TABLE (mengoptimumkan jadual) terpaksa digunakan untuk membina semula jadual dan mengoptimumkan halaman yang diisi.

9 Bagaimanakah ciri ACID transaksi dilaksanakan?

• "Atomicity": Ia dilaksanakan menggunakan log batal Jika ralat berlaku semasa pelaksanaan transaksi atau pengguna melaksanakan rollback, sistem mengembalikan status permulaan transaksi melalui batal log.

• "Kegigihan": Gunakan log buat semula untuk mencapainya selagi log buat semula berterusan, apabila sistem ranap, data boleh dipulihkan melalui log buat semula.

• "Pengasingan": urus niaga diasingkan antara satu sama lain melalui kunci dan MVCC.

• "Ketekalan": Ketekalan dicapai melalui pemulangan semula, pemulihan dan pengasingan dalam situasi serentak.

10 Apakah perbezaan antara MyISAM dan InnoDB dalam cara mereka melaksanakan indeks B-tree?

• Enjin storan InnoDB: nod daun indeks pokok B+ menyimpan data itu sendiri; daripada indeks pepohon B+ Alamat fizikal tempat nod menyimpan data; dan fail data jadualnya sendiri adalah oleh B Struktur indeks yang disusun oleh +Tree Medan data nod pepohon menyimpan rekod data yang lengkap Kunci indeks ini ialah kunci utama bagi jadual data itu sendiri ialah indeks utama. Ini dipanggil "indeks berkelompok" atau indeks Berkelompok, manakala indeks lain digunakan sebagai indeks tambahan Medan data indeks tambahan menyimpan nilai kunci utama rekod yang sepadan dan bukannya alamat . Ini juga berbeza dengan MyISAM.

• 11. Apakah kategori indeks?
Mengikut kandungan nod daun, jenis indeks dibahagikan kepada indeks kunci utama dan indeks kunci bukan utama.

Nod daun indeks kunci primer menyimpan keseluruhan baris data. Dalam InnoDB, indeks kunci utama juga dipanggil indeks berkelompok.

• Kandungan nod daun dalam indeks bukan kunci utama ialah nilai kunci utama. Dalam InnoDB, indeks kunci bukan utama juga dipanggil indeks sekunder.

• 12. Apakah senario yang boleh menyebabkan kegagalan indeks?

• Latar belakang: Keupayaan kedudukan pantas yang disediakan oleh pepohon B+ datang daripada keteraturan nod adik-beradik pada lapisan yang sama, oleh itu, jika ketertiban ini dimusnahkan, ia kemungkinan besar akan gagal berikut: Situasi ini:

Gunakan padanan kabur kiri atau kiri pada indeks: iaitu, seperti %xx atau seperti %xx%. Sebabnya ialah hasil pertanyaan mungkin "Chen Lin, Zhang Lin, Zhou Lin" dan sebagainya, jadi kami tidak tahu nilai indeks mana yang hendak dibandingkan, jadi kami hanya boleh membuat pertanyaan melalui imbasan jadual penuh.

Gunakan fungsi untuk indeks/ungkapan pengiraan untuk indeks: Oleh kerana indeks menyimpan nilai asal medan indeks, dan bukannya nilai yang dikira oleh fungsi, tiada cara untuk menggunakan indeks.

• Penukaran jenis tersirat untuk indeks: bersamaan dengan menggunakan fungsi baharu

• ATAU dalam klausa WHERE: bermaksud dua asalkan Cukup memuaskan satu , jadi tidak masuk akal jika hanya satu lajur bersyarat menjadi lajur indeks Selagi lajur bersyarat bukan lajur indeks, imbasan jadual penuh akan dilakukan.

Cadangan

1. Terdapat sistem yang tidak dibahagikan kepada pangkalan data dan jadual.

• Hentikan pengembangan (tidak disyorkan)

• Pelan migrasi tulis dua kali: Reka pelan struktur jadual dikembangkan, dan kemudian lakukan satu -write migration Perpustakaan dan sub-library melaksanakan dwi-tulisan Selepas memerhati selama seminggu bahawa tiada masalah, matikan trafik baca perpustakaan tunggal Selepas memerhatikan seketika, selepas ia terus stabil, matikan tulis trafik perpustakaan tunggal dan lancar beralih ke sub-pangkalan data dan jadual.

2. Bagaimana untuk mereka bentuk sub-pangkalan data dan penyelesaian jadual yang boleh mengembangkan dan mengecilkan kapasiti secara dinamik?

Prinsip

1.

• Langkah-langkah untuk lapisan Pelayan untuk melaksanakan SQL mengikut turutan ialah:

• Pelanggan permintaan- > Penyambung (sahkan identiti pengguna dan berikan kebenaran) -> ; Pengoptimum (terutamanya memilih kaedah pelan pelaksanaan yang optimum untuk melaksanakan pengoptimuman SQL) -> ke lapisan enjin Dapatkan data dan kembalikannya (jika cache pertanyaan dihidupkan, hasil pertanyaan akan dicache).

2. Apakah prinsip tertib dalaman?

• MySQL akan memperuntukkan memori (sort_buffer) untuk setiap thread untuk mengisih Saiz memori ialah sort_buffer_size.

• Jika jumlah data yang hendak diisih kurang daripada sort_buffer_size, pengisihan akan selesai dalam ingatan.

• Jika jumlah data yang diisih adalah besar dan tidak boleh disimpan dalam memori, fail sementara pada cakera akan digunakan untuk membantu pengisihan, juga dikenali sebagai pengisihan luaran.

• Apabila menggunakan pengisihan luaran, MySQL akan membahagikannya kepada beberapa fail sementara yang berasingan untuk menyimpan data yang diisih, dan kemudian menggabungkan fail ini menjadi satu fail besar.

Prinsip pelaksanaan MVCC?

• MVCC (Kawalan konkurensi berbilang versi) ialah cara untuk mengekalkan berbilang versi data yang sama, dengan itu mencapai kawalan konkurensi. Apabila membuat pertanyaan, cari data versi yang sepadan melalui paparan baca dan rantaian versi.

• Fungsi: Meningkatkan prestasi serentak. Untuk senario konkurensi tinggi, MVCC lebih murah daripada kunci peringkat baris.

• Pelaksanaan MVCC bergantung pada rantaian versi, yang dilaksanakan melalui tiga medan tersembunyi jadual.

• 1) DB_TRX_ID: ID urus niaga semasa, jujukan masa transaksi dinilai mengikut saiz id transaksi.

• 2) DB_ROLL_PRT: Penunjuk putar balik, menunjuk ke versi sebelumnya bagi rekod baris semasa Melalui penunjuk ini, berbilang versi data disambungkan bersama untuk membentuk rantaian versi log asal.

• 3) DB_ROLL_ID: kunci utama Jika jadual data tidak mempunyai kunci utama, InnoDB akan menjana kunci utama secara automatik.

4.

5. Bagaimanakah MySQL memastikan data tidak hilang?

• Selagi redolog dan binlog memastikan cakera berterusan, MySQL pengecualian boleh dipastikan Mekanisme penulisan binlog pemulihan data selepas dimulakan semula.

• redolog memastikan data yang hilang boleh dibuat semula selepas pengecualian sistem dan binlog mengarkibkan data untuk memastikan data yang hilang boleh dipulihkan.

• Tulis redolog sebelum pelaksanaan transaksi, log pertama kali ditulis ke cache binlog Apabila transaksi diserahkan, cache binlog ditulis ke fail binlog .

6. Mengapakah saiz fail jadual kekal tidak berubah walaupun selepas memadamkan jadual?

• Selepas item data dipadamkan, InnoDB menandakan halaman A dan ia akan ditandakan sebagai boleh digunakan semula

• Arahan padam memadam data keseluruhan meja. Akibatnya, semua halaman data akan ditandakan sebagai boleh digunakan semula. Tetapi pada cakera, fail tidak menjadi lebih kecil.

• Jadual yang telah mengalami sejumlah besar penambahan, pemadaman dan pengubahsuaian mungkin mempunyai lubang. Lubang-lubang ini juga mengambil ruang, jadi jika lubang-lubang ini boleh dikeluarkan, tujuan untuk mengecilkan ruang meja boleh dicapai.

• Membina semula jadual boleh mencapai tujuan ini. Anda boleh menggunakan perintah alter table A engine=InnoDB untuk membina semula jadual.

7 Perbandingan tiga format binlog

• Id kunci utama bagi baris operasi yang direkodkan dalam format binlog baris dan id kunci utama setiap baris Nilai sebenar setiap medan, jadi tidak akan ada ketidakkonsistenan dalam data operasi primer dan sekunder.

• kenyataan: pernyataan SQL sumber yang direkodkan

• bercampur: dua yang pertama bercampur, mengapa anda memerlukan fail dalam format bercampur, kerana beberapa kenyataan Format binlog mungkin menyebabkan ketidakkonsistenan antara pelayan utama dan sekunder, jadi format baris mesti digunakan. Tetapi kelemahan format baris ialah ia mengambil banyak ruang. MySQL telah mengambil kompromi MySQL sendiri akan menentukan sama ada pernyataan SQL ini boleh menyebabkan ketidakkonsistenan antara pelayan utama dan sekunder Jika boleh, ia akan menggunakan format baris, jika tidak ia akan menggunakan format pernyataan.

8. Peraturan penguncian MySQL

• Prinsip 1: Unit asas penguncian ialah kunci kekunci seterusnya -kunci kunci ialah selang terbuka dan tertutup.

• Prinsip 2: Hanya objek yang diakses semasa proses carian akan dikunci

• Pengoptimuman 1: Pertanyaan setara pada indeks, berikan unik Apabila indeks dikunci, kunci kekunci seterusnya merosot menjadi kunci baris.

• Pengoptimuman 2: Untuk pertanyaan setara pada indeks, apabila merentasi ke kanan dan nilai terakhir tidak memenuhi syarat kesetaraan, kunci kekunci seterusnya merosot menjadi kunci celah

• Pepijat: pertanyaan julat pada indeks unik akan mengakses nilai pertama yang tidak memenuhi syarat.

9. Apakah bacaan kotor, bacaan tidak boleh diulang dan bacaan hantu?

• "Bacaan kotor": Bacaan kotor merujuk kepada membaca data tanpa komitmen daripada urus niaga lain bermakna data itu boleh ditarik balik, yang bermaksud ia tidak boleh digunakan penghujungnya. Ia akan disimpan dalam pangkalan data, iaitu data yang tidak wujud. Membaca data yang mungkin akhirnya tidak wujud dipanggil bacaan kotor.

• "Bacaan tidak boleh berulang": Bacaan tidak boleh berulang bermaksud bahawa dalam transaksi, data yang dibaca pada permulaan adalah tidak konsisten dengan kumpulan data yang sama dibaca pada bila-bila masa sebelum tamat daripada situasi transaksi.

• "Bacaan hantu": Bacaan hantu tidak bermakna set hasil yang diperolehi oleh dua bacaan adalah berbeza Fokus bacaan hantu ialah status data hasil yang diperolehi oleh pilihan tertentu operasi tidak dapat menyokong operasi perniagaan seterusnya. Untuk lebih spesifik: pilih sama ada rekod tertentu wujud Jika ia tidak wujud, sediakan untuk memasukkan rekod Walau bagaimanapun, apabila melaksanakan sisipan, didapati rekod itu sudah wujud dan tidak boleh dimasukkan pada masa ini berlaku.

10 Apakah jenis kunci yang ada pada MySQL? >Dari segi jenis kunci, terdapat kunci kongsi dan kunci eksklusif.

• 1) Kunci kongsi: juga dipanggil kunci baca Apabila pengguna ingin membaca data, kunci kongsi ditambahkan pada data masa yang sama.

• 2) Kunci eksklusif: juga dipanggil kunci tulis Apabila pengguna ingin menulis data, tambahkan kunci eksklusif pada data Hanya satu kunci eksklusif boleh ditambah, dia dan Eksklusif yang lain kunci dan kunci kongsi adalah saling eksklusif.

• Kebutiran kunci bergantung pada enjin storan khusus InnoDB melaksanakan kunci peringkat baris, kunci peringkat halaman dan kunci peringkat jadual.

• overhed pengunciannya meningkat daripada besar kepada kecil, dan keupayaan penyelarasannya juga meningkat daripada besar kepada kecil.

• Kerangka

1. Apakah prinsip replikasi tuan-hamba Mysql?

• Acara kemas kini Master (kemas kini, sisip, padam) akan ditulis kepada bin-log mengikut urutan. Apabila hamba disambungkan kepada tuan, mesin tuan akan membuka benang binlog dump untuk hamba, dan benang akan membaca log bin-log.

• Selepas Slave disambungkan kepada Master, perpustakaan Slave mempunyai I/O线程 yang membaca log bin-log dengan meminta benang dump binlog, dan kemudian menulisnya ke relay log log perpustakaan hamba.

• Slave juga mempunyai SQL线程, yang memantau kandungan log relay dalam masa nyata untuk kemas kini, menghuraikan pernyataan SQL dalam fail dan melaksanakannya dalam pangkalan data Slave.

2. Apakah kaedah penyegerakan replikasi tuan-hamba untuk Mysql?

• Replikasi tak segerak: Penyegerakan induk-hamba MySQL ialah replikasi tak segerak secara lalai. Iaitu, antara tiga langkah di atas, hanya langkah pertama adalah segerak (iaitu, Mater menulis log log bin), iaitu, perpustakaan induk boleh berjaya kembali kepada klien selepas menulis log binlog, tanpa menunggu binlog log untuk dipindahkan ke perpustakaan hamba.

• Replikasi segerak: Untuk replikasi segerak, selepas hos Master menghantar acara kepada hos Hamba, penantian akan dicetuskan sehingga semua nod Hamba (jika terdapat berbilang Hamba) mengembalikan maklumat tentang replikasi data yang berjaya kepada Master.

• Replikasi separa segerak: Untuk replikasi separa segerak, selepas hos Master menghantar acara kepada hos Hamba, penantian akan dicetuskan sehingga salah satu daripada Nod hamba (jika (Terdapat berbilang Hamba) mengembalikan maklumat tentang replikasi data yang berjaya kepada Master.

3 Apakah yang menyebabkan kelewatan penyegerakan tuan-hamba Mysql?

• Jika nod induk melaksanakan transaksi yang besar, ia akan memberi kesan yang lebih besar pada kelewatan induk-hamba

• Kelewatan Rangkaian , log besar, terlalu ramai hamba

• Tulisan berbilang benang pada induk, hanya penyegerakan satu benang pada nod hamba

• Prestasi mesin isu , sama ada nod hamba menggunakan "mesin buruk"

• Isu konflik kunci juga boleh menyebabkan utas SQL hamba dilaksanakan dengan perlahan

4. Apakah yang menyebabkan kelewatan penyegerakan tuan-hamba Mysql Bagaimana untuk mengoptimumkannya?

• Transaksi besar: Bahagikan transaksi besar kepada transaksi kecil dan kemas kini data dalam kelompok

• Kurangkan bilangan Hamba kepada tidak lebih daripada 5 untuk mengurangkan saiz satu transaksi

• Selepas Mysql 5.7, anda boleh menggunakan replikasi berbilang benang dan menggunakan seni bina replikasi MGR

• pada cakera, serbuan Jika terdapat masalah dengan kad atau strategi penjadualan, kelewatan IO tunggal mungkin sangat tinggi Anda boleh menggunakan arahan iostat untuk menyemak situasi IO cakera data DB, dan kemudian menilai lagi

  <.>
• untuk menyelesaikan masalah kunci Semak dengan mengambil senarai proses dan melihat jadual yang berkaitan dengan kunci dan transaksi di bawah information_schema.

6.

• log bin ialah fail di peringkat pangkalan data Mysql. Ia merekodkan semua operasi yang mengubah suai pangkalan data Mysql tidak akan direkodkan.

• Data yang akan dikemas kini direkodkan dalam log buat semula Contohnya, jika sekeping data berjaya diserahkan, ia tidak akan disegerakkan ke cakera serta-merta, tetapi akan direkodkan. dalam log buat semula dahulu dan tunggu muat semula cakera yang sesuai apabila ada peluang, untuk mencapai ketahanan transaksi.

• log asal digunakan untuk operasi panggil balik data Ia mengekalkan kandungan sebelum rekod diubah suai. Balik semula transaksi boleh dicapai melalui log buat asal dan MVCC boleh dilaksanakan dengan menjejak kembali ke versi data tertentu berdasarkan log buat asal.

Atas ialah kandungan terperinci Apakah isu asas dengan MySQL?. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!