Mari analisa prinsip aliran kerja transaksi MySQL bersama-sama

Artikel ini membawakan anda pengetahuan yang berkaitan tentang mysql, yang terutamanya memperkenalkan isu yang berkaitan dengan prinsip aliran kerja transaksi, termasuk atomicity transaksi dicapai melalui log asal, dan transaksi Kegigihan dicapai melalui log semula dan sebagainya. Mari kita lihat. Saya harap ia akan membantu semua orang.

Pembelajaran yang disyorkan: tutorial video mysql

• Keatomisan transaksi dicapai melalui log asal
• Ketahanan urus niaga dicapai melalui log semula
• Pengasingan urus niaga dicapai melalui (kunci baca-tulis MVCC)
• Dan konsistensi bos muktamad urus niaga Dicapai melalui atomicity, ketekunan, dan pengasingan! ! !

1 buat semula log untuk mencapai kegigihan

Masalah. 1: Mengapa anda perlu buat semula log?

InnoDB ialah enjin storan MySQL Data disimpan pada cakera Walau bagaimanapun, jika cakera IO diperlukan setiap kali untuk membaca dan menulis data , kecekapan akan dikurangkan Sangat rendah. Untuk tujuan ini, InnoDB menyediakan cache (Kolam Penampan) sebagai penimbal untuk mengakses pangkalan data: apabila membaca data daripada pangkalan data, ia akan dibaca terlebih dahulu daripada Kolam Penampan Jika tiada kolam penampan, ia akan dibaca daripada cakera dan dimasukkan ke dalam Buffer Pool apabila menulis data ke pangkalan data, ia akan ditulis ke Buffer Pool terlebih dahulu, dan data yang diubah suai dalam Buffer Pool akan sentiasa dimuat semula ke cakera.

Penggunaan Buffer Pool sangat meningkatkan kecekapan membaca dan menulis data, tetapi ia juga membawa masalah baharu: jika MySQL tidak berfungsi dan data yang diubah suai dalam Buffer Pool tidak dibuang ke cakera, ia akan menyebabkan Kehilangan data dan ketahanan transaksi tidak dapat dijamin.

Soalan 2: Bagaimanakah buat semula log memastikan ketahanan transaksi?

Log buat semula boleh dibahagikan kepada dua bahagian berikut:

Yang pertama ialah penimbal log buat semula dalam memori ( redo log buffer ), tidak menentu, dan disimpan dalam ingatan

Yang kedua ialah fail log buat semula, yang berterusan dan disimpan pada cakera

Mari kita bincangkan tentang menulis Buat semula secara terperinci di sini Masa:

Selepas pengubahsuaian halaman data selesai, sebelum halaman kotor dikeluarkan dari cakera, log buat semula ditulis. Ambil perhatian bahawa data diubah suai dahulu, dan kemudian log ditulis

Log buat semula ditulis semula ke cakera sebelum halaman data

Pengubahsuaian indeks berkelompok, indeks sekunder dan buat asal halaman semua perlu direkodkan dalam log Redo

Dalam MySQL, jika setiap operasi kemas kini perlu ditulis ke cakera, maka cakera mesti juga cari rekod yang sepadan dan kemudian kemas kininya Kos IO dan kos carian keseluruhan proses adalah sangat tinggi. Untuk menyelesaikan masalah ini, pereka bentuk MySQL menggunakan log (redo log) untuk meningkatkan kecekapan kemas kini.

Apabila transaksi dilakukan, penimbal log buat semula mula-mula ditulis pada fail log buat semula untuk kegigihan, dan ia tidak selesai sehingga operasi komit transaksi selesai. Pendekatan ini juga dipanggil Log Tulis Ke Hadapan (kegigihan pra-log Sebelum meneruskan halaman data, halaman log yang sepadan dalam memori dikekalkan.

Khususnya, apabila rekod perlu dikemas kini, enjin InnoDB akan menulis rekod terlebih dahulu ke log buat semula (penimbalan log semula) dan mengemas kini memori (kolam penimbal Pada masa ini, kemas kini selesai). . Pada masa yang sama, enjin InnoDB akan mengemas kini rekod operasi ini ke cakera (siram halaman kotor) pada masa yang sesuai (seperti apabila sistem melahu).

Berbilang halaman boleh diubah suai dalam satu urus niaga Log Tulis Ke Hadapan boleh memastikan konsistensi satu halaman data, tetapi tidak dapat menjamin ketahanan urus niaga tersebut adalah komited , semua log transaksi mini yang dihasilkan mesti disiram ke cakera Jika selepas siram log selesai, pangkalan data ranap sebelum halaman dalam kumpulan penimbal disiram ke peranti storan berterusan, kemudian apabila pangkalan data dimulakan semula, log. boleh digunakan untuk memastikan integriti Data.

Soalan 3: Apakah proses menulis semula log?

Rajah di atas menunjukkan proses penulisan log semula Setiap transaksi mini sepadan dengan setiap operasi DML, seperti penyata kemas kini, yang dijamin oleh transaksi mini Selepas data diubah suai, buat semula1 , mula-mula tulis ke dalam Penimbal peribadi transaksi mini Selepas penyata kemas kini tamat, salin buat semula1 daripada Penimbal peribadi kepada Penimbal Log awam. Apabila keseluruhan urus niaga luaran dilakukan, penimbal log buat semula dibuang ke dalam fail log buat semula. (Log buat semula ditulis secara berurutan, dan bacaan dan penulisan berurutan cakera adalah lebih pantas daripada pembacaan dan penulisan rawak)

Soalan 4: Penulisan data Adakah peletakan terakhir dikemas kini daripada log buat semula atau kumpulan penimbal?

Sebenarnya, log buat semula tidak merekodkan data lengkap halaman data, jadi ia tidak mempunyai keupayaan untuk mengemas kini halaman data cakera dengan sendirinya, jadi ia tidak boleh Terdapat situasi di mana data lepas yang dikemas kini oleh log buat semula akhirnya diletakkan pada cakera.

① Selepas halaman data diubah suai, ia tidak konsisten dengan halaman data pada cakera, yang dipanggil halaman kotor. Data akhir ditulis pada cakera dengan menulis halaman data dalam memori ke cakera. Proses ini tiada kena mengena dengan buat semula log.

② Dalam senario pemulihan ranap sistem, jika InnoDB menentukan bahawa halaman data mungkin telah kehilangan kemas kininya semasa pemulihan ranap sistem, ia akan membacanya ke dalam memori dan kemudian membenarkan log buat semula mengemas kini kandungan memori. Selepas kemas kini selesai, halaman memori menjadi halaman kotor dan kembali kepada keadaan situasi pertama

Soalan 5: Apakah itu redo log penampan? Perlukah saya mengubah suai memori terlebih dahulu atau menulis fail log semula dahulu?

Semasa proses kemas kini transaksi, log perlu ditulis beberapa kali. Contohnya, transaksi berikut:

Copybegin;

MASUKKAN KE DALAM NILAI T1 ('1', '1');

MASUKKAN KE DALAM NILAI T2 ('1', '1 ');

komit;

Transaksi ini akan memasukkan rekod ke dalam dua jadual semasa proses memasukkan data, log yang dijana mesti disimpan dahulu, tetapi ia tidak boleh dilakukan sebelum ia komited apabila tiba masanya, tulis terus ke fail log buat semula.

Oleh itu, penampan semula log diperlukan Ia adalah sekeping memori yang digunakan untuk menyimpan semula log terlebih dahulu. Dalam erti kata lain, apabila sisipan pertama dilaksanakan, memori data diubah suai dan penimbal log buat semula juga ditulis pada log.

Walau bagaimanapun, log sebenarnya ditulis pada fail log buat semula apabila pernyataan komit dilaksanakan.

Penimbal log buat semula pada asasnya hanyalah tatasusunan bait, tetapi untuk mengekalkan penimbal ini, banyak data meta lain perlu ditetapkan, yang kesemuanya terkandung dalam struktur log_t.

Soalan 6: Adakah buat semula log ditulis ke cakera secara berurutan?

Log buat semula menulis fail secara berurutan Apabila semua fail penuh, ia kembali ke kedudukan permulaan yang sepadan bagi fail pertama melakukan timpa, selepas setiap transaksi diserahkan, log operasi yang berkaitan ditulis terlebih dahulu ke dalam fail log semula dan dilampirkan pada penghujung fail Ini ialah I/O berurutan

<.>

Gambar menunjukkan satu set log redo 4 fail. tunggu Siram halaman kotor). Bahagian antara pos tulis dan pusat semak boleh digunakan untuk merekodkan operasi baharu Jika pos tulis dan titik semak bertemu, ini bermakna log buat semula penuh Pada masa ini, pangkalan data berhenti melaksanakan penyata kemas kini pangkalan data dan sebaliknya menyegerakkan log buat semula cakera itu. Bahagian antara pusat pemeriksaan dan pos tulis sedang menunggu cakera ditulis (mula-mula kemas kini halaman memori, dan kemudian tunggu halaman kotor disiram).

Dengan log buat semula, apabila pangkalan data dimulakan semula secara tidak normal, ia boleh dipulihkan berdasarkan log buat semula, yang selamat daripada ranap sistem.

log buat semula digunakan untuk memastikan keupayaan selamat ranap. Apabila parameter innodb_flush_log_at_trx_commit ditetapkan kepada 1, ini bermakna log buat semula setiap transaksi diteruskan terus ke cakera. Adalah disyorkan untuk menetapkan parameter ini kepada 1 untuk memastikan bahawa data tidak akan hilang selepas MySQL dimulakan semula secara tidak normal

2 Log bin

MySQL sebenarnya mempunyai dua bahagian: Satu ialah lapisan pelayan, yang kebanyakannya melakukan perkara di peringkat fungsi MySQL yang satu lagi ialah lapisan enjin, yang bertanggungjawab untuk perkara berkaitan storan tertentu. Log buat semula yang kita bincangkan di atas ialah log unik untuk enjin InnoDB, dan lapisan pelayan juga mempunyai log sendiri, dipanggil binlog (log arkib)

Kenapa ada dua batang kayu?

Kerana tiada enjin InnoDB dalam MySQL pada mulanya. Enjin MySQL sendiri ialah MyISAM, tetapi MyISAM tidak mempunyai keupayaan selamat ranap, dan log binlog hanya boleh digunakan untuk pengarkiban. InnoDB telah diperkenalkan kepada MySQL dalam bentuk pemalam oleh syarikat lain Memandangkan hanya bergantung pada binlog tidak mempunyai keupayaan selamat ranap, InnoDB menggunakan sistem log lain, iaitu, buat semula log, untuk mencapai keupayaan selamat ranap.

Kedua-dua log ini mempunyai tiga perbezaan berikut.

① log buat semula adalah unik untuk enjin InnoDB binlog dilaksanakan oleh lapisan Pelayan MySQL dan boleh digunakan oleh semua enjin.

② log semula ialah log fizikal, yang merekodkan "pengubahsuaian yang dibuat pada halaman data tertentu"; binlog ialah log logik, yang merekodkan logik asal pernyataan ini, seperti "beri ID=2 ini Medan c bagi satu baris ditambah dengan 1".

③ Log buat semula ditulis dalam gelung, dan ruang akan sentiasa habis; "Tambahkan tulisan" bermaksud bahawa selepas fail binlog mencapai saiz tertentu, ia akan bertukar kepada yang seterusnya dan tidak akan menimpa log sebelumnya.

Selepas memahami konseptual kedua-dua log ini, mari kita lihat proses dalaman pelaksana dan enjin InnoDB apabila melaksanakan kenyataan kemas kini ini. .

① Pelaksana terlebih dahulu mencari enjin untuk mendapatkan ID talian=2. ID ialah kunci utama dan enjin terus menggunakan carian pokok untuk mencari baris ini. Jika halaman data di mana baris dengan ID=2 terletak sudah berada dalam ingatan, ia akan dikembalikan terus kepada pelaksana jika tidak, ia perlu dibaca ke dalam memori dari cakera terlebih dahulu dan kemudian dikembalikan.

② Pelaksana mendapat data baris yang diberikan oleh enjin, menambah 1 pada nilai ini, contohnya, dulu N, tetapi kini N 1, mendapat baris data baharu, dan kemudian memanggil antara muka enjin untuk menulis baris data baharu ini.

③ Enjin mengemas kini baris data baharu ini ke dalam memori (InnoDB Buffer Pool) dan merekodkan operasi kemas kini ke dalam log buat semula Pada masa ini, log buat semula berada dalam keadaan sediakan. Kemudian maklumkan kepada pelaksana bahawa pelaksanaan telah selesai dan transaksi boleh diserahkan pada bila-bila masa.

④ Pelaksana menjana binlog operasi ini dan menulis binlog ke cakera.

⑤ Pelaksana memanggil antara muka transaksi komit enjin, dan enjin menukar log buat semula yang baru ditulis kepada keadaan komit, dan kemas kini selesai

di mana Pisahkan penulisan log semula kepada dua langkah: menyediakan dan komit Ini adalah masalah komit dua fasa (2PC) 1: Apakah prinsip penyerahan dua peringkat?

MySQL menggunakan komit dua fasa untuk menyelesaikan masalah ketekalan data binlog dan buat semula log. Penerangan prinsip komit dua fasa: ① log buat semula ditulis pada cakera dan transaksi InnoDB memasuki keadaan sediakan.

② Jika persediaan sebelumnya berjaya dan binlog ditulis pada cakera, kemudian teruskan log transaksi ke binlog Jika kegigihan berjaya, transaksi InnoDB akan memasuki keadaan komit.

buat semula log dan binlog mempunyai medan data biasa yang dipanggil XID. Semasa pemulihan ranap sistem, log buat semula akan diimbas mengikut tertib:

① Jika log buat semula dengan kedua-dua persediaan dan komitmen ditemui, ia akan diserahkan terus

② Jika ia ditemui sahaja; parepare dan komit Jika tiada log buat semula komit, gunakan XID untuk mencari transaksi yang sepadan dalam binlog.

Tiada rekod dalam binlog, transaksi rollback

Ada rekod dalam binlog, commit transaksi

Soalan 2 : Mengapa Mesti ada "komitmen dua fasa"?

Jika penyerahan dua fasa tidak digunakan, anggap bahawa nilai medan c ialah 0 untuk baris semasa dengan ID=2, dan kemudian andaikan bahawa semasa pelaksanaan kenyataan kemas kini Selepas menulis log pertama, ranap berlaku sebelum log kedua ditulis Apakah yang akan berlaku? **Tulis buat semula log dahulu dan kemudian binlog. ** Katakan proses MySQL dimulakan semula secara tidak normal apabila log buat semula selesai tetapi sebelum binlog selesai. Seperti yang kami katakan sebelum ini, selepas log buat semula ditulis, walaupun sistem ranap, data masih boleh dipulihkan, jadi nilai c dalam baris ini selepas pemulihan ialah 1. Tetapi kerana binlog ranap sebelum ia selesai, kenyataan ini tidak direkodkan dalam binlog pada masa ini. Oleh itu, apabila log disandarkan kemudian, kenyataan ini tidak akan dimasukkan ke dalam binlog yang disimpan.

Kemudian anda akan mendapati bahawa jika anda perlu menggunakan binlog ini untuk memulihkan perpustakaan sementara, kerana binlog pernyataan ini hilang, perpustakaan sementara akan terlepas kemas kini ini, dan nilai c dalam baris yang dipulihkan akan menjadi 0 , berbeza daripada nilai perpustakaan asal.

**Tulis binlog dahulu dan kemudian buat semula log. **Jika terdapat ranap sistem selepas binlog ditulis, memandangkan log buat semula belum ditulis lagi, transaksi akan menjadi tidak sah selepas pemulihan ranap, jadi nilai c dalam baris ini ialah 0. Tetapi log "Tukar c dari 0 kepada 1" telah direkodkan dalam binlog. Oleh itu, apabila binlog digunakan untuk memulihkan kemudian, satu lagi transaksi akan keluar Nilai c dalam baris yang dipulihkan ialah 1, yang berbeza daripada nilai dalam pangkalan data asal.

Seperti yang anda lihat, jika "komit dua fasa" tidak digunakan, keadaan pangkalan data mungkin tidak konsisten dengan keadaan perpustakaan yang dipulihkan menggunakan lognya.

Ringkasnya, log buat semula dan binlog boleh digunakan untuk mewakili status komit transaksi, dan komit dua fasa adalah untuk memastikan kedua-dua keadaan itu konsisten secara logik.

3. Buat asal log mencapai atomicity

Batal log mempunyai dua fungsi: menyediakan kawalan balik dan berbilang versi (MVCC) )

Apabila data diubah suai, bukan sahaja buat semula direkodkan, tetapi juga buat asal yang sepadan direkodkan terutamanya logik data. Perubahan, untuk melancarkan operasi sebelumnya apabila ralat berlaku, semua operasi sebelumnya perlu direkodkan, dan kemudian ia boleh digulung semula apabila ralat berlaku.

buat asal log hanya memulihkan pangkalan data kepada keadaan asalnya Semasa rollback, ia sebenarnya melakukan kerja yang bertentangan Sebagai contoh, INSERT sepadan dengan DELETE, dan untuk setiap KEMASKINI, ia sepadan dengan kemas kini terbalik. belakang baris sebelum pengubahsuaian. Log buat asal digunakan untuk operasi rollback transaksi untuk memastikan atomicity transaksi.

Kunci untuk mencapai atomicity ialah dapat membuat asal semua pernyataan SQL yang berjaya dilaksanakan apabila transaksi ditarik balik. InnoDB melaksanakan pemulangan semula dengan bergantung pada log buat asal: apabila transaksi mengubah suai pangkalan data, InnoDB akan menjana log buat asal yang sepadan Jika pelaksanaan urus niaga gagal atau pemulangan dipanggil, menyebabkan urus niaga ditarik balik, maklumat dalam log buat asal boleh. digunakan untuk Data digulung semula seperti sebelum pengubahsuaian.

Dalam enjin storan InnoDB, buat asal log terbahagi kepada:

masukkan buat asal log

kemas kini log buat asal

masukkan buat asal log merujuk kepada operasi sisipan Log buat asal yang dijana adalah kerana rekod operasi sisipan hanya boleh dilihat oleh transaksi itu sendiri dan bukan kepada transaksi lain. Oleh itu, log buat asal boleh dipadamkan terus selepas transaksi diserahkan, dan tiada operasi pembersihan diperlukan.

Log buat asal kemas kini merekodkan log buat asal yang dijana oleh operasi pemadaman dan kemas kini Log buat asal mungkin perlu menyediakan mekanisme MVCC, jadi ia tidak boleh dipadamkan apabila transaksi dilakukan. Apabila menyerahkan, masukkannya ke dalam senarai log batal dan tunggu benang pembersihan melakukan pemadaman terakhir.

Tambahan: Dua fungsi utama benang pembersihan ialah: membersihkan halaman buat asal dan mengosongkan baris data dengan bendera Delete_Bit dalam halaman. Dalam InnoDB, operasi Padam dalam transaksi sebenarnya tidak memadamkan baris data, tetapi operasi Padam Tanda yang menandakan Delete_Bit pada rekod tanpa memadamkan rekod. Ia adalah sejenis "pemadaman palsu", yang hanya ditandakan Kerja pemadaman sebenar perlu diselesaikan oleh benang pembersihan latar belakang.

Innodb menggunakan B-tree sebagai struktur data indeks, dan indeks tempat kunci utama terletak ialah ClusterIndex (indeks berkelompok), dan kandungan data yang sepadan disimpan dalam nod daun dalam ClusterIndex. Jadual hanya boleh mempunyai satu kunci utama, jadi hanya boleh ada satu indeks berkelompok Jika jadual tidak menentukan kunci utama, indeks unik bukan NULL pertama dipilih sebagai indeks berkelompok lajur id dijana sebagai indeks berkelompok.

Indeks selain Indeks Kluster ialah Indeks Sekunder (indeks tambahan). Nod daun dalam indeks tambahan menyimpan nilai nod daun indeks berkelompok.

Selain rowid yang baru disebut, rekod baris InnoDB juga termasuk trx_id dan db_roll_ptr mewakili id ​​urus niaga yang diubah suai baru-baru ini dan db_roll_ptr menghala ke log buat asal dalam segmen buat asal.

Apabila transaksi baharu ditambahkan, id transaksi akan ditingkatkan dan trx_id boleh menunjukkan susunan transaksi dimulakan.

Buat asal log terbahagi kepada dua jenis: Masukkan dan Kemas kini padam boleh dianggap sebagai kemas kini khas, iaitu mengubah suai tanda pemadaman pada rekod.

Log buat asal kemas kini merekodkan maklumat data sebelumnya, yang melaluinya keadaan versi sebelumnya boleh dipulihkan.

Apabila melakukan operasi sisipan, log buat asal Sisip yang dijana boleh dipadamkan selepas transaksi dilakukan, kerana transaksi lain tidak memerlukan log buat asal ini.

Apabila memadam dan mengubah suai operasi, log buat asal yang sepadan akan dijana, dan db_roll_ptr dalam rekod data semasa akan menghala ke log buat asal baharu

4 🎜>

MVCC (MultiVersion Concurrency Control) dipanggil kawalan penukaran berbilang versi.

MVCC InnoDB dilaksanakan dengan menyimpan dua lajur tersembunyi di belakang setiap baris rekod. Daripada dua lajur ini, satu menjimatkan masa penciptaan baris, dan satu lagi menjimatkan masa tamat tempoh baris Sudah tentu, apa yang disimpan bukanlah nilai masa sebenar, tetapi nombor versi sistem.

Idea pelaksanaan utama ialah memisahkan bacaan dan penulisan melalui berbilang versi data. Ini membolehkan membaca tidak berkunci dan membaca dan menulis selari.

Pelaksanaan MVCC dalam mysql bergantung pada undo log dan read view

• Buat asal log: Buat asal log merekodkan berbilang versi baris data tertentu.
• pandangan baca: digunakan untuk menentukan keterlihatan versi semasa data

Paparan baca yang konsisten yang digunakan oleh InnoDB semasa melaksanakan MVCC, iaitu paparan baca yang konsisten, digunakan untuk menyokong RC (Read Committed , read commit) dan RR (Repeatable Read, repeatable read) pelaksanaan tahap pengasingan.

Di bawah tahap pengasingan baca berulang, transaksi "mengambil gambar" apabila ia bermula.

Petikan MVCC MySQL tidak menyalin maklumat pangkalan data untuk setiap transaksi, tetapi dilaksanakan berdasarkan nombor versi sistem yang disimpan di belakang setiap baris maklumat dalam jadual data. Seperti yang ditunjukkan dalam rajah di bawah, berbilang versi deretan maklumat wujud bersama, dan setiap transaksi mungkin membaca versi yang berbeza

Setiap transaksi dalam InnoDB mempunyai ID transaksi unik , dipanggil id transaksi. Ia digunakan pada sistem urus niaga InnoDB pada permulaan urus niaga, dan dinaikkan secara ketat mengikut susunan permohonan.

Dan setiap baris data juga mempunyai berbilang versi. Setiap kali transaksi mengemas kini data, versi data baharu dijana dan id urus niaga diberikan kepada baris trx_id versi data ini. Pada masa yang sama, versi data lama harus dikekalkan, dan dalam versi data baharu, mungkin terdapat maklumat yang boleh diperoleh secara langsung.

Barisan rekod dalam jadual data sebenarnya mungkin mempunyai berbilang versi (baris) dan setiap versi mempunyai trx_id barisnya sendiri. Ia adalah keadaan selepas rekod telah dikemas kini secara berterusan oleh berbilang transaksi.

Dalam kotak bertitik dalam rajah terdapat 4 versi baris data yang sama. Nilai k ialah 22 , iaitu Transaksi dengan id transaksi 25 dikemas kini, jadi baris trx_idnya juga 25.

Adakah kemas kini penyata akan menjana log asal (log putar balik)? Jadi, di manakah log buat asal?

Sebenarnya, tiga anak panah bertitik dalam Rajah 2 adalah log asal V1, V2 dan V3 tidak wujud secara fizikal, tetapi dikira berdasarkan versi semasa dan buat asal log setiap kali ia diperlukan. Sebagai contoh, apabila V2 diperlukan, ia dikira dengan melaksanakan U3 dan U2 secara berurutan melalui V4.

Mengikut takrifan bacaan berulang, apabila transaksi dimulakan, semua keputusan transaksi yang diserahkan dapat dilihat. Tetapi kemudian, semasa urus niaga ini dilaksanakan, kemas kini daripada urus niaga lain tidak dapat dilihat olehnya. Oleh itu, transaksi hanya perlu mengisytiharkan apabila ia dimulakan, "Berdasarkan saat saya memulakannya, jika versi data dijana sebelum saya memulakannya, ia akan dikenali; jika ia dijana selepas saya memulakannya, saya tidak akan mengenalinya." , saya perlu mencari versi sebelumnya". Sudah tentu, jika "versi sebelumnya" tidak kelihatan sama ada, anda perlu terus melihat ke hadapan. Selain itu, jika data dikemas kini oleh transaksi itu sendiri, ia masih perlu mengenalinya.

5. Teknologi kunci MySQL

Apabila terdapat berbilang permintaan untuk membaca data dalam jadual, tiada tindakan boleh diambil, tetapi terdapat permintaan baca antara berbilang permintaan , dan mesti ada langkah untuk mengawal konkurensi apabila terdapat permintaan pengubahsuaian. Jika tidak, ketidakkonsistenan mungkin berlaku. Kunci baca-tulis menyelesaikan masalah di atas dengan mudah Anda hanya perlu menggunakan gabungan dua kunci untuk mengawal permintaan baca dan tulis

Dua kunci ini dipanggil:

Dikongsi. kunci (kunci kongsi), juga dipanggil "kunci baca", kunci baca boleh dikongsi atau berbilang permintaan baca boleh berkongsi kunci untuk membaca data tanpa menyebabkan sekatan.

Kunci eksklusif (kunci eksklusif), juga dipanggil "kunci tulis". dilepaskan.

Ringkasan: Melalui kunci baca-tulis, membaca dan membaca boleh dilakukan secara selari, tetapi menulis dan membaca, dan menulis dan menulis tidak boleh dilakukan secara selari. Pengasingan dicapai melalui kunci baca-tulis! ! !

Pembelajaran yang disyorkan: tutorial video mysql

Atas ialah kandungan terperinci Mari analisa prinsip aliran kerja transaksi MySQL bersama-sama. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!