Mari kita bercakap secara mendalam tentang ciri transaksi dan prinsip pelaksanaan dalam MySQL

Artikel ini akan membincangkan tentang ciri transaksi dalam MySQL dan memperkenalkan prinsip pelaksanaan MVCC kawalan konkurensi berbilang versi. Saya harap ia akan membantu semua orang!

1 Konsep

Transaksi secara amnya merujuk kepada set operasi logik , atau sebagai satu siri operasi yang dilakukan oleh unit logik tunggal Semua operasi dalam urus niaga akan dirangkumkan ke dalam unit pelaksanaan yang tidak boleh dibahagikan Semua operasi dalam unit ini akan dilaksanakan dengan jayanya atau semua gagal, selagi mana-mana satu operasi dilaksanakan. . Jika gagal, keseluruhan transaksi akan ditarik balik.

2. Pengenalan kepada ciri dan jenis transaksi

2.1 Ciri-ciri transaksi

Atomicity

Atomicity urus niaga bermakna semua operasi yang membentuk urus niaga sama ada semuanya berjaya dilaksanakan atau semuanya gagal.

Ketekalan

Ketekalan urus niaga bermakna data sentiasa dalam keadaan konsisten sebelum dan selepas urus niaga dilaksanakan.

Pengasingan

Pengasingan urus niaga merujuk kepada tidak campur tangan antara dua urus niaga yang dilaksanakan secara serentak, iaitu, pelaksanaan urus niaga Semasa proses, anda tidak dapat melihat status perantaraan transaksi lain yang menjalankan proses.

?‍ Nota: MySQL memastikan pengasingan transaksi dengan mengunci mekanisme MVCC.

Kegigihan (tempoh)

Ketahanan transaksi bermakna apabila transaksi dilakukan, perubahan pada data yang dibuat oleh transaksi ini kehendak diteruskan ke pangkalan data dan tidak akan ditarik balik.

2.2 Pengenalan kepada dua jenis transaksi

• Transaksi setempat
• Transaksi teragih

Tempatan urus niaga

Transaksi yang biasanya dikawal berdasarkan pangkalan data hubungan boleh dipanggil transaksi tradisional atau transaksi tempatan.

Proses pelaksanaan transaksi setempat

• Sebelum pelanggan memulakan operasi transaksi, ia perlu untuk didayakan Jawapan sambungan;

• Selepas memulakan balasan, pelanggan memulakan arahan untuk memulakan urus niaga; , pelanggan menghantar pelbagai data proses Penyata SQL; 🎜>

• Setelah proses di atas selesai, tutup sesi.

• ✔Urus niaga tempatan diuruskan secara tempatan oleh pengurus sumber.

• Kelemahan urus niaga tempatan ialah:

Tidak mempunyai keupayaan untuk memproses transaksi yang diedarkan

Proses transaksi boleh hanya disambungkan Pangkalan data yang menyokong transaksi tidak boleh digunakan dengan berbilang pangkalan data transaksi.

3. Apakah masalah yang akan dibawa oleh transaksi serentak

Kehilangan kemas kini (tulisan kotor)

Apabila dua atau lebih urus niaga mengendalikan baris data yang sama pada masa yang sama dan mengemas kini baris data dengan nilai asal yang dipilih, transaksi itu dianggap tidak dapat melihat kewujudan satu sama lain , jadi operasi kemas kini terakhir akan menulis ganti operasi kemas kini yang dilengkapkan oleh transaksi sebelumnya yang lain.

Contohnya:

Akaun Zhang San ialah 100 yuan Pada masa ini terdapat dua transaksi: transaksi 1 dan transaksi 2. Transaksi 1 adalah untuk memindahkan baki Zhang San. akaun Tambah 100 yuan Transaksi 2 meningkatkan baki Zhang San sebanyak 200. Pada mulanya, transaksi 1 dan transaksi 2 membaca baki akaun Zhang San sebanyak 100 yuan pada masa yang sama Kemudian transaksi 1 dan transaksi 2 kemas kini Zhang Sanyue terlebih dahulu Diserahkan dalam transaksi 2, tetapi selepas dua transaksi terbaharu diserahkan, baki Zhang San ialah 300 yuan (biasanya 400 yuan), iaitu: transaksi 2 yang diserahkan kemudian menimpa operasi kemas kini transaksi 1 , ini Ia adalah apa yang dipanggil kehilangan kemas kini (tulisan kotor) pada asasnya adalah konflik operasi tulis Walau bagaimanapun, cara untuk menyelesaikan penulisan kotor adalah dengan melaksanakan setiap transaksi secara bersiri untuk memastikan transaksi melaksanakan operasi tulis dalam susunan tertentu. .

Bacaan kotor

Satu transaksi membaca data tidak komited daripada transaksi lain. Contohnya: Transaksi 1 menambah 100 yuan kepada baki Zhang San Sebelum transaksi ini diserahkan, transaksi 2 lain membaca data yang diubah suai Jika tiada transaksi di bawah kawalan, transaksi kedua akan membacanya belum diserahkan dikesan, dan langkah seterusnya untuk memproses kluster data kotor, akan ada pergantungan pada data yang tidak dikomit Biasanya fenomena ini dipanggil 脏读, iaitu : Bacaan kotor ialah apabila satu transaksi membaca data yang tidak dikomitkan daripada transaksi lain.

?Bacaan kotor pada asasnya adalah konflik antara operasi baca dan tulis Penyelesaiannya adalah dengan menulis dahulu dan kemudian membaca, iaitu membaca selepas menulis .

Bacaan tidak boleh berulang

Transaksi membaca data tertentu Selepas tempoh masa, transaksi ini membaca semula data yang dibaca sebelum ini mendapati bahawa data yang dibaca telah berubah, atau beberapa rekod data telah dipadamkan, fenomena ini dipanggil: bacaan tidak boleh diulang,

iaitu, transaksi yang sama, menggunakan pernyataan pertanyaan yang sama, dibaca pada masa yang berbeza. keputusan yang diperoleh adalah tidak konsisten.

Bacaan tidak boleh berulang pada asasnya adalah konflik antara operasi baca dan tulis Penyelesaiannya ialah membaca dahulu dan kemudian menulis, iaitu menulis selepas membaca.

Bacaan hantu

Transaksi membaca semula data yang dibaca sebelum ini mengikut syarat pertanyaan yang sama Pada masa ini, didapati bahawa transaksi lain ada data yang disisipkan yang memenuhi syarat pertanyaan semasa Dengan data baharu, set hasil data menjadi lebih besar Fenomena ini dipanggil bacaan hantu, iaitu, satu transaksi membaca julat rekod data dua kali, dan hasil dibaca dua kali adalah berbeza.

Bacaan hantu pada asasnya adalah konflik antara operasi baca dan tulis Penyelesaiannya ialah membaca dahulu dan kemudian menulis, iaitu menulis selepas membaca.

Pada ketika ini, ramai rakan mempunyai soalan Intipati yang sama adalah konflik antara operasi membaca dan menulis bacaan hantu?, Saya Lihat di bawah untuk penjelasan ringkas:

• 1️⃣ Fokus bacaan tidak boleh berulang ialah operasi kemas kini dan padam, manakala fokus bacaan hantu ialah operasi sisipan.

• 2️⃣ Apabila MySQL menggunakan mekanisme kunci untuk melaksanakan tahap pengasingan transaksi, dalam tahap pengasingan baca berulang, selepas pernyataan SQL pertama membaca data, data yang sepadan akan dikunci, supaya urus niaga lain tidak boleh mengubah suai dan memadam data ini, dan bacaan berulang dicapai melalui penguncian. Walau bagaimanapun, kaedah ini tidak boleh mengunci sisipan data baharu Jika transaksi 1 membaca data, atau mengubah suai atau memadam data, transaksi 2 juga boleh melakukan operasi sisipan, menyebabkan transaksi 1 menambah sekeping data tambahan yang tidak tersedia. sebelum ini. Ini adalah bacaan hantu.

• 3️⃣ Oleh itu, bacaan hantu tidak boleh dielakkan melalui mekanisme kunci Tahap pengasingan transaksi bersiri perlu digunakan, tetapi tahap pengasingan transaksi ini akan mengurangkan keupayaan konkurensi pangkalan data.

✔MySQL menggunakan mekanisme MVCC (Multiple Version Concurrency Control) untuk mengelakkan bacaan tidak berulang dan bacaan hantu.

4 Tahap pengasingan urus niaga MySQL

Gunakan arahan berikut untuk membuat pertanyaan peringkat global dan peringkat sesi urus niaga tahap pengasingan:

# 默认数据库的事务隔离级别为：可重复读（REPEATABLE-READ）
SELECT @@global.tx_isolation;
SELECT @@session.tx_isolation;
SELECT @@tx_isolation;

5 MVCC kawalan penukaran berbilang versi

Berbilang-. version concurrency control , Multi-Version Concurrency Control ialah kaedah kawalan concurrency, biasanya digunakan dalam sistem pengurusan pangkalan data untuk mencapai akses serentak kepada pangkalan data. MVCC

Kelebihan MVCC berbanding kunci

Anda boleh menganggap

sebagai kompromi penguncian peringkat baris, yang mengelakkan penggunaan kunci dalam banyak kes, Pada masa yang sama, ia boleh memberikan overhed yang lebih kecil. Bergantung pada pelaksanaan, ia boleh membenarkan bacaan tanpa menyekat, mengunci hanya rekod yang diperlukan semasa penulisan berlaku. MVCC

MVCC的实现原理

MVCC的是通过保存数据澡某个时间点的快照来实现的，也就是说，不管事务执行多长的时间，每个事务看到的数据都是一致的。根据事务的开始时间不同，每个事务对同一张表，同一时刻看到的数据可能是不一样的。InnonDB主要通过为每一行记录添加两个额外的隐藏的值来实现MVCC，这两个值一个记录这行数据何时被创建，另外一个记录这行数据何时过期（或者被删除）。但是InnoDB并不存储这些事件发生时的 实际时间 ，相反它只存储这些事件发生时的系统 版本号（version） 。这是一个随着事务的创建而不断增长的数字。每个事务在事务开始时会记录它自己的系统版本号。每个查询必须去检查每行数据的版本号与事务的版本号是否相同。

《高性能MySQL》书籍中介绍到：

MVCC只在REPEATABLE READ和READ COMMITTIED两个隔离级别下工作，其他两个隔离级别都和MVCC不兼容，因为READ UNCOMMITTED总是读取最新的数据行，而不符合当前事务版本数据行，而SERIALIZABLE串行化隔离级别则会对所有读取的行都加锁。

接下来举个例子说明在可重复读事务隔离级别下，MVCC机制是如何完成增删改查操作的。

• 查询操作（SELECT）

在查询操作中，InnoDB存储引擎跟根据以下两个条件查询对应的行记录，只有满足对应条件才会被返回：

1️⃣ 只查找不晚于当前事务版本的数据行，也就是说，InnoDB存储引擎只会查找版本号小于或者等于当前事务版本的数据行，这些数据行要么在该事务开始前就存在，要么就是事务本身插入或者更新的行。
2️⃣ 对于数据删除，数据行删除的版本要么还没有被定义，要么大于当前事务的版本号，只有这样才能确保事务读到的行，在事务开始前并没有被删除。

举个例子，存在 事务A 和 事务B 两个事务，事务A中存在两套相同的SELECT语句，事务B存在一条UPDATE语句，事务A 的第一条查询语句在事务B提交之前执行，第二条查询语句在 事务B 提交之后执行，事务A 如下所示：

-- 事务A操作
START TRANSACTION;
SELECT * FROM account WHERE id = 1;     //在事务B提交之前执行
SELECT * FROM account WHERE id = 1;     //在事务B提交之后执行
COMMIT;

事务B：

-- 事务B操作
START TRANSACTION;
UPDATE account SET balance = balance+100 WHERE id = 1;
COMMIT;

✔结论：如果没有使用MVCC机制，则事务A中的第一条SELECT语句读取的数据是修改前的数据，而第二条SELECT语句读取的是修改后的数据，两次读取的数据不一致，想想，那不就乱了吗?? 如果使用了MVCC机制，无论事务B如何修改数据，事务A的两条查询语句的到的结果始终是一致的。

• 插入操作（SELECT）

在插入操作中，InnoDB会将新插入的每一条行记录的当前系统版本包保存为行版本号。

比如：向account表插入一条数据，同时MVCC的两个版本号分别为create_version和delete_version，create_version代表创建行的版本号，delete_version代表删除行的版本号，另外还有一个事务ID字段，如下面所示：

INSERT INTO account(id, name, balance) values(1001, 'austin', 100);

对应的版本号信息如下表：

id	name	balance	transaction_id	create_version	delete_version
1001	austin	100	1	1	未定义

可以看出，当向数据表新增记录时，需要设置保存行的版本号，而删除行的版本号未定义。

• 更新操作（SELECT）

在更新操作中，InnoDB存储引擎会插入一行新记录，并保存当前系统的版本号为新记录行的版本号，同时保存当前系统的版本号到原来数据行作为删除标识。比如：将account数据表中id为1001的用户账户月增加100元，对应SQL如下：

UPDATE account SET balance = balance+100 WHERE id = 1001;

执行SQL, 在MVCC机制下的更新操作如下表所示：

id	name	balance	transaction_id	create_version	delete_version
1001	austin	100	1	1	2
1001	austin	200	2	2	未定义

可以明显看出，执行更新操作时，MVCC机制是先将原来的数据复制一份，将balance字段增加100后，再讲create_version字段的值设置为当前系统的版本号，而delete_version字段的值未定义。

注意的是：原来的行会被复制到Undo Log中。

• 删除操作（SELECT）

在删除操作中，InnoDB存储引擎会保存删除的每一个行记录当前的系统版本号，作为删除标识。比如：删除account数据表中id为1001的数据，SQL如下所示：

DELETE FROM account WHERE id = 1001;

对应MVCC机制下的删除操作如下表所示：

id	name	balance	transaction_id	create_version	delete_version
1001	austin	200	3	2	3

可以看出，当删除数据表数据行时，MVCC机制会将当前系统的版本号写入删除数据行版本字段delete_version中，以此来表示当前数据行已经被删除。

六、总结

本文主要讲述了事务的特性、类型和本地事务和分布式事务的区别，通过不同的示例解释并发事务带来的更新丢失、脏读、不可重复读、幻读的问题，同时介绍了多版本并发控制MVCC的实现原理，如果文章对你有帮助，感谢点赞?+评论?+收藏❤，我是：?‍?austin流川枫，我们下期见!

【相关推荐：mysql视频教程】

Atas ialah kandungan terperinci Mari kita bercakap secara mendalam tentang ciri transaksi dan prinsip pelaksanaan dalam MySQL. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!