Artikel ini membawakan anda pengetahuan yang berkaitan tentang mysql, yang terutamanya memperkenalkan isu-isu yang berkaitan dengan prinsip MVCC InnoDB ialah kawalan konkurensi berbilang versi, terutamanya untuk meningkatkan keselarasan pangkalan data, mari lihatlah, semoga bermanfaat untuk semua.
Pembelajaran yang disyorkan: tutorial video mysql
MVCC adalah singkatan kepada Multi-Version Concurrency Control, iaitu kawalan konkurensi berbilang versi, terutamanya untuk Meningkatkan prestasi konkurensi pangkalan data. Apabila permintaan baca atau tulis berlaku untuk baris data yang sama, permintaan itu akan dikunci dan disekat. Tetapi MVCC menggunakan cara yang lebih baik untuk mengendalikan permintaan baca-tulis, supaya tiada penguncian berlaku apabila konflik permintaan baca-tulis berlaku. Bacaan ini merujuk kepada bacaan syot kilat, bukan bacaan semasa Bacaan semasa ialah operasi mengunci dan merupakan kunci pesimis. Jadi bagaimanakah ia mencapai membaca dan menulis tanpa mengunci Apakah maksud bacaan syot kilat dan bacaan semasa? Kita semua akan belajar ini nanti.
MySQL sebahagian besarnya boleh mengelakkan masalah bacaan hantu di bawah tahap pengasingan REPEATABLE READ Bagaimana MySQL melakukan ini?
Kami tahu bahawa untuk jadual yang menggunakan enjin storan InnoDB, rekod indeks berkelompoknya mengandungi dua lajur tersembunyi yang diperlukan (row_id Ia tidak perlu. Lajur row_id tidak akan disertakan apabila jadual yang kami cipta mempunyai kunci utama atau kunci UNIK bukan NULL):
trx_id: Setiap kali transaksi mengelompokkan item tertentu Apabila rekod indeks diubah suai , ID transaksi transaksi akan diberikan kepada lajur tersembunyi trx_id.
roll_pointer: Setiap kali rekod indeks berkelompok ditukar, versi lama akan ditulis pada log buat asal, dan kemudian lajur tersembunyi ini bersamaan dengan penunjuk, yang boleh Gunakannya untuk cari maklumat sebelum rekod diubah suai.
Untuk menggambarkan masalah ini, kami mencipta jadual tunjuk cara:
CREATE TABLE `teacher` ( `number` int(11) NOT NULL, `name` varchar(100) DEFAULT NULL, `domain` varchar(100) DEFAULT NULL, PRIMARY KEY (`number`)) ENGINE=InnoDB DEFAULT CHARSET=utf8
dan kemudian masukkan sekeping data ke dalam jadual ini:
mysql> insert into teacher values(1, 'J', 'Java');Query OK, 1 row affected (0.01 sec)
Data kini kelihatan seperti ini:
mysql> select * from teacher; +--------+------+--------+ | number | name | domain | +--------+------+--------+ | 1 | J | Java | +--------+------+--------+ 1 row in set (0.00 sec)
Dengan mengandaikan bahawa ID transaksi yang dimasukkan ke dalam rekod ialah 60, maka gambarajah skematik rekod pada masa ini adalah seperti berikut:
Anggapkan bahawa dua transaksi dengan ID transaksi 80 dan 120 melakukan operasi KEMASKINI pada rekod ini Proses operasi adalah seperti berikut:
| Trx80 | Trx120 |
|---|---|
| begin | |
| begin | |
| update teacher set name=‘S’ where number=1; | |
| update teacher set name=‘T’ where number=1; | |
| commit | |
| update teacher set name=‘K’ where number=1; | |
| update teacher set name=‘F’ where number=1; | |
| commit |
每次对记录进行改动，都会记录一条undo日志，每条undo日志也都有一个roll_pointer属性（INSERT操作对应的undo日志没有该属性，因为该记录并没有更早的版本），可以将这些undo日志都连起来，串成一个链表，所以现在的情况就像下图一样：
对该记录每次更新后，都会将旧值放到一条undo日志中，就算是该记录的一个旧版本，随着更新次数的增多，所有的版本都会被roll_pointer属性连接成一个链表，我们把这个链表称之为版本链，版本链的头节点就是当前记录最新的值。另外，每个版本中还包含生成该版本时对应的事务id。于是可以利用这个记录的版本链来控制并发事务访问相同记录的行为，那么这种机制就被称之为多版本并发控制(Mulit-Version Concurrency Control MVCC)。
对于使用READ UNCOMMITTED隔离级别的事务来说，由于可以读到未提交事务修改过的记录，所以直接读取记录的最新版本就好了。
对于使用SERIALIZABLE隔离级别的事务来说，InnoDB使用加锁的方式来访问记录。
对于使用READ COMMITTED和REPEATABLE READ隔离级别的事务来说，都必须保证读到已经提交了的事务修改过的记录，也就是说假如另一个事务已经修改了记录但是尚未提交，是不能直接读取最新版本的记录的，核心问题就是：READ COMMITTED和REPEATABLE READ隔离级别在不可重复读和幻读上的区别，这两种隔离级别关键是需要判断一下版本链中的哪个版本是当前事务可见的。
为此，InnoDB提出了一个ReadView的概念，这个ReadView中主要包含4个比较重要的内容：
m_ids：表示在生成ReadView时当前系统中活跃的读写事务的事务id列表。
min_trx_id：表示在生成ReadView时当前系统中活跃的读写事务中最小的事务id，也就是m_ids中的最小值。
max_trx_id：表示生成ReadView时系统中应该分配给下一个事务的id值。注意max_trx_id并不是m_ids中的最大值，事务id是递增分配的。比方说现在有id为1，2，3这三个事务，之后id为3的事务提交了。那么一个新的读事务在生成ReadView时，m_ids就包括1和2，min_trx_id的值就是1，max_trx_id的值就是4。
creator_trx_id：表示生成该ReadView的事务的事务id。
有了这个ReadView，这样在访问某条记录时，只需要按照下边的步骤判断记录的某个版本是否可见：
在MySQL中，READ COMMITTED和REPEATABLE READ隔离级别的的一个非常大的区别就是它们生成ReadView的时机不同。
我们还是以表teacher为例，假设现在表teacher中只有一条由事务id为60的事务插入的一条记录，接下来看一下READ COMMITTED和REPEATABLE READ所谓的生成ReadView的时机不同到底不同在哪里。
假设现在系统里有两个事务id分别为80、120的事务在执行：
# Transaction 80 set session transaction isolation level read committed; begin update teacher set name='S' where number=1; update teacher set name='T' where number=1;
此刻，表teacher中number为1的记录得到的版本链表如下所示：
假设现在有一个使用READ COMMITTED隔离级别的事务开始执行：
set session transaction isolation level read committed; # 使用READ COMMITTED隔离级别的事务 begin; # SELECE1：Transaction 80、120未提交 SELECT * FROM teacher WHERE number = 1; # 得到的列name的值为'J'
这个SELECE1的执行过程如下：
在执行SELECT语句时会先生成一个ReadView，ReadView的m_ids列表的内容就是[80, 120]，min_trx_id为80，max_trx_id为121，creator_trx_id为0。
然后从版本链中挑选可见的记录，最新版本的列name的内容是’T’，该版本的trx_id值为80，在m_ids列表内，根据步骤4不符合可见性要求，根据roll_pointer跳到下一个版本。
下一个版本的列name的内容是’S’，该版本的trx_id值也为80，也在m_ids列表内，根据步骤4也不符合要求，继续跳到下一个版本。
下一个版本的列name的内容是’J’，该版本的trx_id值为60，小于ReadView 中的min_trx_id值，根据步骤2判断这个版本是符合要求的。
之后，我们把事务id为80的事务提交一下，然后再到事务id为120的事务中更新一下表teacher 中number为1的记录：
set session transaction isolation level read committed; # Transaction 120 begin update teacher set name='K' where number=1; update teacher set name='F' where number=1;
此刻，表teacher 中number为1的记录的版本链就长这样：
然后再到刚才使用READ COMMITTED隔离级别的事务中继续查找这个number 为1的记录，如下：
# 使用READ COMMITTED隔离级别的事务 begin; # SELECE1：Transaction 80、120未提交 SELECT * FROM teacher WHERE number = 1; # 得到的列name的值为'J' # SELECE2：Transaction 80提交、120未提交 SELECT * FROM teacher WHERE number = 1; # 得到的列name的值为'T'
这个SELECE2 的执行过程如下：
以此类推，如果之后事务id为120的记录也提交了，再次在使用READCOMMITTED隔离级别的事务中查询表teacher中number值为1的记录时，得到的结果就是’F’了，具体流程我们就不分析了。
总结一下就是：使用READCOMMITTED隔离级别的事务在每次查询开始时都会生成一个独立的ReadView。
对于使用REPEATABLE READ隔离级别的事务来说，只会在第一次执行查询语句时生成一个ReadView，之后的查询就不会重复生成了。我们还是用例子看一下是什么效果。
假设现在系统里有两个事务id分别为80、120的事务在执行：
# Transaction 80 begin update teacher set name='S' where number=1; update teacher set name='T' where number=1;
此刻，表teacher中number为1的记录得到的版本链表如下所示：
假设现在有一个使用REPEATABLE READ隔离级别的事务开始执行：
# 使用REPEATABLE READ隔离级别的事务 begin; # SELECE1：Transaction 80、120未提交 SELECT * FROM teacher WHERE number = 1; # 得到的列name的值为'J'
这个SELECE1的执行过程如下（与READ COMMITTED的过程一致）：
在执行SELECT语句时会先生成一个ReadView，ReadView的m_ids列表的内容就是[80, 120]，min_trx_id为80，max_trx_id为121，creator_trx_id为0。
然后从版本链中挑选可见的记录，最新版本的列name的内容是’T’，该版本的trx_id值为80，在m_ids列表内，根据步骤4不符合可见性要求，根据roll_pointer跳到下一个版本。
下一个版本的列name的内容是’S’，该版本的trx_id值也为80，也在m_ids列表内，根据步骤4也不符合要求，继续跳到下一个版本。
下一个版本的列name的内容是’J’，该版本的trx_id值为60，小于ReadView 中的min_trx_id值，根据步骤2判断这个版本是符合要求的。
之后，我们把事务id为80的事务提交一下，然后再到事务id为120的事务中更新一下表teacher 中number为1的记录：
# Transaction 80 begin update teacher set name='K' where number=1; update teacher set name='F' where number=1;
此刻，表teacher 中number为1的记录的版本链就长这样：
然后再到刚才使用REPEATABLE READ隔离级别的事务中继续查找这个number为1的记录，如下：
# 使用REPEATABLE READ隔离级别的事务 begin; # SELECE1：Transaction 80、120未提交 SELECT * FROM teacher WHERE number = 1; # 得到的列name的值为'J' # SELECE2：Transaction 80提交、120未提交 SELECT * FROM teacher WHERE number = 1; # 得到的列name的值为'J'
这个SELECE2的执行过程如下：
Maksudnya, hasil yang diperolehi oleh dua pertanyaan SELECT diulang, dan nilai lajur yang direkodkan adalah semua '''J'''' Ini adalah maksud bacaan berulang.
Jika kami menyerahkan rekod dengan ID urus niaga 120 kemudian, dan kemudian terus mencari rekod dengan nombor 1 dalam urus niaga yang baru sahaja menggunakan tahap pengasingan REPEATABLE READ, hasilnya akan tetap 'J', khususnya Anda boleh menganalisis sendiri proses pelaksanaan.
Kita sedia maklum sebelum ini bahawa MVCC boleh menyelesaikan masalah bacaan tidak boleh berulang di bawah tahap pengasingan BACA BERULANG, jadi hantu membaca kain bulu? Bagaimanakah MVCC diselesaikan? Bacaan hantu ialah apabila transaksi membaca rekod berbilang kali mengikut syarat yang sama, dan bacaan terakhir membaca rekod yang belum dibaca sebelum ini, dan rekod ini datang daripada rekod baharu yang ditambahkan oleh transaksi lain.
Kita boleh memikirkannya, transaksi T1 di bawah tahap pengasingan BACA BOLEH DIULANG mula-mula membaca berbilang rekod berdasarkan keadaan carian tertentu, kemudian transaksi T2 memasukkan rekod yang memenuhi syarat carian yang sepadan dan menyerahkannya, dan kemudian transaksi T1 Kemudian laksanakan pertanyaan berdasarkan kriteria carian yang sama. Apakah hasilnya? Mengikut peraturan perbandingan dalam ReadView:
Tidak kira sama ada transaksi T2 dibuka sebelum transaksi T1, transaksi T1 tidak dapat melihat penyerahan T2. Sila analisa sendiri mengikut rantaian versi, ReadView dan peraturan penghakiman keterlihatan yang diperkenalkan di atas.
Walau bagaimanapun, MVCC dalam InnoDB di bawah tahap pengasingan REPEATABLE READ boleh mengelakkan bacaan hantu pada tahap yang besar, dan bukannya melarang bacaan hantu sepenuhnya. Apa yang berlaku? Mari lihat situasi berikut:
| T1 | T2 |
|---|---|
| begin; | |
| select * from teacher where number=30; 无数据 | begin; |
| insert into teacher values(30, ‘X’, ‘Java’); | |
| commit; | |
| update teacher set domain=‘MQ’ where number=30; | |
| select * from teacher where number = 30; 有数据 |
Hmm, apa yang berlaku? Transaksi T1 jelas mempunyai fenomena bacaan hantu. Di bawah tahap pengasingan REPEATABLE READ, T1 menjana ReadView apabila melaksanakan pernyataan SELECT biasa untuk kali pertama, dan kemudian T2 memasukkan rekod baharu ke dalam jadual guru dan menyerahkannya. ReadView tidak boleh menghalang T1 daripada melaksanakan kenyataan KEMASKINI atau PADAM untuk mengubah suai rekod yang baru dimasukkan (memandangkan T2 telah diserahkan, menukar rekod tidak akan menyebabkan penyekatan), tetapi dengan cara ini, nilai lajur tersembunyi trx_id rekod baharu ini akan menjadi Ia menjadi id transaksi T1. Selepas itu, T1 boleh melihat rekod ini apabila ia menggunakan pernyataan SELECT biasa untuk menanyakan rekod ini dan boleh mengembalikan rekod ini kepada klien. Kerana kewujudan fenomena istimewa ini, kita juga boleh berfikir bahawa MVCC tidak boleh melarang membaca hantu sepenuhnya.
Daripada penerangan di atas, kita dapat melihat bahawa apa yang dipanggil MVCC (Multi-Version ConcurrencyControl, kawalan konkurensi berbilang versi) merujuk kepada penggunaan READ COMMITTD dan REPEATABLE READ .
Perbezaan besar antara dua tahap pengasingan READ COMMITTD dan REPEATABLE READ ialah masa menjana ReadView adalah berbeza READ COMMITTD akan menjana ReadView sebelum setiap operasi SELECT biasa, manakala REPEATABLE READ hanya akan menghasilkan ReadView. selepas operasi SELECT biasa yang pertama Hanya jana ReadView sebelum melakukan operasi SELECT biasa, dan gunakan semula ReadView ini untuk operasi pertanyaan seterusnya, dengan itu pada dasarnya mengelakkan fenomena bacaan hantu.
Kami berkata sebelum ini bahawa melaksanakan kenyataan DELETE atau kenyataan KEMASKINI yang mengemas kini kunci utama tidak akan memadam sepenuhnya rekod yang sepadan daripada halaman sebaliknya, ia akan melakukan apa yang dipanggil operasi tanda padam, iaitu sama dengan hanya menandakan rekod dengan tanda Padam bit bendera, yang berfungsi terutamanya MVCC. Di samping itu, apa yang dipanggil MVCC hanya berkuat kuasa apabila kami melakukan pertanyaan SEELCT biasa Semua pernyataan SELECT yang kami lihat setakat ini adalah pertanyaan biasa Bagi pertanyaan yang luar biasa, kami akan membincangkannya kemudian.
Pembelajaran yang disyorkan: tutorial video mysql
Atas ialah kandungan terperinci MySQL meringkaskan prinsip MVCC InnoDB. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!
![[Web front-end] Permulaan pantas Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
