Rumah >pangkalan data >tutorial mysql >Membolehkan anda memahami tahap pengasingan transaksi dalam MySQL melalui kes
Artikel ini akan membantu anda memahami tahap pengasingan transaksi dalam MySQL melalui empat kes saya harap ia akan membantu semua orang!
Ramai rakan yang sentiasa keliru tentang tahap pengasingan MySQL sebenarnya, masalah ini tidak sukar sama sekali. Melihat teori sahaja pasti akan membuat anda pening, tetapi jika kami menunjukkannya melalui beberapa SQL sebenar, semua orang akan mendapati bahawa perkara ini sangat mudah! [Cadangan berkaitan: tutorial video mysql]
Hari ini Brother Song ingin menunjukkan isu tahap pengasingan transaksi dalam MySQL melalui beberapa kes mudah.
Terdapat empat tahap pengasingan transaksi dalam MySQL, seperti berikut:
Empat yang berbeza Maksud tahap pengasingan adalah seperti berikut:
BOLEH BERSIRI
Jika tahap pengasingan adalah bersiri, pengguna lulus satu demi satu Laksanakan transaksi semasa secara berurutan ini memberikan pengasingan maksimum antara transaksi.
BACA YANG BOLEH DIULANG
Pada tahap pengasingan ini, urus niaga tidak dianggap sebagai urutan. Walau bagaimanapun, perubahan dalam urus niaga yang sedang dilaksanakan masih tidak kelihatan kepada pihak luar Maksudnya, jika pengguna melaksanakan penyataan SELECT yang sama beberapa kali dalam transaksi lain, hasilnya akan sentiasa sama. (Kerana perubahan data yang dihasilkan oleh transaksi yang melaksanakan tidak dapat dilihat oleh dunia luar).
READ COMMITTED
READ COMMITTED tahap pengasingan kurang selamat berbanding REPEATABLE READ isolation level. Urus niaga di peringkat READ COMMITTED boleh melihat pengubahsuaian data oleh transaksi lain. Iaitu, beberapa penyata SELECT untuk transaksi yang sama mungkin mengembalikan hasil yang berbeza jika transaksi lain mengubah suai jadual yang sepadan semasa transaksi.
READ UNCOMMITTED
READ UNCOMMITTED menyediakan pengasingan minimum antara transaksi. Selain menjana operasi baca hantu dengan mudah dan operasi baca tidak boleh berulang, urus niaga pada tahap pengasingan ini boleh membaca data yang belum dilakukan oleh transaksi lain Jika transaksi ini menggunakan perubahan yang tidak dilakukan oleh transaksi lain sebagai asas pengiraan, maka perubahan tidak komited itu akan Perubahan komited dibuat asal oleh transaksi induk mereka, yang mengakibatkan sejumlah besar perubahan data.
Dalam pangkalan data MySQL, tahap pengasingan urus niaga lalai ialah REPEATABLE READ
Seterusnya , kami akan mengesahkan teori di atas kepada pembaca melalui beberapa SQL mudah.
Anda boleh melihat tahap pengasingan global lalai bagi contoh pangkalan data dan tahap pengasingan sesi semasa melalui SQL berikut:
Digunakan sebelum MySQL8 Jalankan arahan berikut untuk melihat tahap pengasingan MySQL:
SELECT @@GLOBAL.tx_isolation, @@tx_isolation;
Hasil pertanyaan adalah seperti yang ditunjukkan dalam rajah:
Seperti yang anda lihat, tahap pengasingan lalai ialah BACA BOLEH DIULANG, global Ini benar untuk tahap pengasingan dan tahap pengasingan sesi semasa.
Bermula dari MySQL8, gunakan arahan berikut untuk melihat tahap pengasingan lalai MySQL :
SELECT @@GLOBAL.transaction_isolation, @@transaction_isolation;
Hanya kata kunci telah berubah, yang lain adalah sama.
Tahap pengasingan boleh diubah suai melalui arahan berikut (pembangun disyorkan untuk mengubah suai tahap pengasingan sesi semasa apabila mengubah suai, tanpa mengubah suai tahap pengasingan global):
SET SESSION TRANSACTION ISOLATION LEVEL READ UNCOMMITTED
SQL di atas menunjukkan Tetapkan tahap pengasingan pangkalan data sesi semasa kepada READ UNCOMMITTED Selepas tetapan berjaya, tanya tahap pengasingan sekali lagi dan mendapati tahap pengasingan sesi semasa telah berubah, seperti yang ditunjukkan dalam Rajah 1-2:
<.>Perhatikan bahawa jika anda hanya mengubah suai tahap pengasingan sesi semasa, selepas menukar sesi, tahap pengasingan akan kembali ke tahap pengasingan lalai, jadi apabila kami menguji, hanya ubah suai tahap pengasingan sesi semasa.
2.2 BACA TAK KOMITED2.2.1 Sediakan data ujianREAD UNCOMMITTED ialah tahap pengasingan terendah Dalam tahap pengasingan ini, terdapatbacaan kotor , tidak tersedia Masalah bacaan berulang dan bacaan hantu , jadi di sini kita lihat tahap pengasingan ini, supaya semua orang dapat memahami apakah ketiga-tiga masalah ini.
Mereka diperkenalkan di bawah. Mula-mula buat jadual ringkas dengan dua data pratetap, seperti berikut:表的数据很简单,有 javaboy 和 itboyhub 两个用户,两个人的账户各有 1000 人民币。现在模拟这两个用户之间的一个转账操作。
注意,如果读者使用的是 Navicat 的话,不同的查询窗口就对应了不同的 session,如果读者使用了 SQLyog 的话,不同查询窗口对应同一个 session,因此如果使用 SQLyog,需要读者再开启一个新的连接,在新的连接中进行查询操作。
一个事务读到另外一个事务还没有提交的数据,称之为脏读。具体操作如下:
首先打开两个SQL操作窗口,假设分别为 A 和 B,在 A 窗口中输入如下几条 SQL (输入完成后不用执行):
START TRANSACTION; UPDATE account set balance=balance+100 where name='javaboy'; UPDATE account set balance=balance-100 where name='itboyhub';COMMIT;
在 B 窗口执行如下 SQL,修改默认的事务隔离级别为 READ UNCOMMITTED,如下:
SET SESSION TRANSACTION ISOLATION LEVEL READ UNCOMMITTED
接下来在 B 窗口中输入如下 SQL,输入完成后,首先执行第一行开启事务(注意只需要执行一行即可):
START TRANSACTION;SELECT * from account;COMMIT;
接下来执行 A 窗口中的前两条 SQL,即开启事务,给 javaboy 这个账户添加 100 元。
进入到 B 窗口,执行 B 窗口的第二条查询 SQL(SELECT * from user;),结果如下:
可以看到,A 窗口中的事务,虽然还未提交,但是 B 窗口中已经可以查询到数据的相关变化了。
这就是脏读问题。
不可重复读是指一个事务先后读取同一条记录,但两次读取的数据不同,称之为不可重复读。具体操作步骤如下(操作之前先将两个账户的钱都恢复为1000):
首先打开两个查询窗口 A 和 B ,并且将 B 的数据库事务隔离级别设置为 READ UNCOMMITTED。具体 SQL 参考上文,这里不赘述。
在 B 窗口中输入如下 SQL,然后只执行前两条 SQL 开启事务并查询 javaboy 的账户:
START TRANSACTION;SELECT * from account where name='javaboy';COMMIT;
前两条 SQL 执行结果如下:
START TRANSACTION; UPDATE account set balance=balance+100 where name='javaboy';COMMIT;
4.再次回到 B 窗口,执行 B 窗口的第二条 SQL 查看 javaboy 的账户,结果如下:
javaboy 的账户已经发生了变化,即前后两次查看 javaboy 账户,结果不一致,这就是不可重复读。
和脏读的区别在于,脏读是看到了其他事务未提交的数据,而不可重复读是看到了其他事务已经提交的数据(由于当前 SQL 也是在事务中,因此有可能并不想看到其他事务已经提交的数据)。
幻象读和不可重复读非常像,看名字就是产生幻觉了。
我举一个简单例子。
在 A 窗口中输入如下 SQL:
START TRANSACTION;insert into account(name,balance) values('zhangsan',1000);COMMIT;
然后在 B 窗口输入如下 SQL:
START TRANSACTION;SELECT * from account;delete from account where name='zhangsan';COMMIT;
我们执行步骤如下:
首先执行 B 窗口的前两行,开启一个事务,同时查询数据库中的数据,此时查询到的数据只有 javaboy 和 itboyhub。
执行 A 窗口的前两行,向数据库中添加一个名为 zhangsan 的用户,注意不用提交事务。
执行 B 窗口的第二行,由于脏读问题,此时可以查询到 zhangsan 这个用户。
执行 B 窗口的第三行,去删除 name 为 zhangsan 的记录,这个时候删除就会出问题,虽然在 B 窗口中可以查询到 zhangsan,但是这条记录还没有提交,是因为脏读的原因才看到了,所以是没法删除的。此时就产生了幻觉,明明有个 zhangsan,却无法删除。
这就是幻读。
看了上面的案例,大家应该明白了脏读、不可重复读以及幻读各自是什么含义了。
和 READ UNCOMMITTED 相比,READ COMMITTED 主要解决了脏读的问题,对于不可重复读和幻象读则未解决。
将事务的隔离级别改为 READ COMMITTED
之后,重复上面关于脏读案例的测试,发现已经不存在脏读问题了;重复上面关于不可重复读案例的测试,发现不可重复读问题依然存在。
上面那个案例不适用于幻读的测试,我们换一个幻读的测试案例。
还是两个窗口 A 和 B,将 B 窗口的隔离级别改为 READ COMMITTED
,
然后在 A 窗口输入如下测试 SQL:
START TRANSACTION;insert into account(name,balance) values('zhangsan',1000);COMMIT;
在 B 窗口输入如下测试 SQL:
START TRANSACTION;SELECT * from account;insert into account(name,balance) values('zhangsan',1000);COMMIT;
测试方式如下:
首先执行 B 窗口的前两行 SQL,开启事务并查询数据,此时查到的只有 javaboy 和 itboyhub 两个用户。
执行 A 窗口的前两行 SQL,插入一条记录,但是并不提交事务。
执行 B 窗口的第二行 SQL,由于现在已经没有了脏读问题,所以此时查不到 A 窗口中添加的数据。
执行 B 窗口的第三行 SQL,由于 name 字段唯一,因此这里会无法插入。此时就产生幻觉了,明明没有 zhangsan 这个用户,却无法插入 zhangsan。
和 READ COMMITTED 相比,REPEATABLE READ 进一步解决了不可重复读的问题,但是幻象读则未解决。
REPEATABLE READ 中关于幻读的测试和上一小节基本一致,不同的是第二步中执行完插入 SQL 后记得提交事务。
由于 REPEATABLE READ 已经解决了不可重复读,因此第二步即使提交了事务,第三步也查不到已经提交的数据,第四步继续插入就会出错。
注意,REPEATABLE READ 也是 InnoDB 引擎的默认数据库事务隔离级别
SERIALIZABLE 提供了事务之间最大限度的隔离,在这种隔离级别中,事务一个接一个顺序的执行,不会发生脏读、不可重复读以及幻象读问题,最安全。
如果设置当前事务隔离级别为 SERIALIZABLE,那么此时开启其他事务时,就会阻塞,必须等当前事务提交了,其他事务才能开启成功,因此前面的脏读、不可重复读以及幻象读问题这里都不会发生。
总的来说,隔离级别和脏读、不可重复读以及幻象读的对应关系如下:
隔离级别 | 脏读 | 不可重复读 | 幻象读 |
---|---|---|---|
READ UNCOMMITTED | 允许 | 允许 | 允许 |
READ COMMITED | 不允许 | 允许 | 允许 |
REPEATABLE READ | 不允许 | 不允许 | 允许 |
SERIALIZABLE | 不允许 | 不允许 | 不允许 |
性能关系如图:
好了,这篇文章就和小伙伴们先说这么多,大家不妨写几行 SQL 试一试。
更多编程相关知识,请访问:编程视频!!
Atas ialah kandungan terperinci Membolehkan anda memahami tahap pengasingan transaksi dalam MySQL melalui kes. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!