no | no |
|
MySQL의 기본 트랜잭션 격리 수준은 반복 읽기입니다
IV. 예제를 사용하여 각 격리 수준 설명
1. 커밋되지 않은 읽기:
(1) 클라이언트 A를 열고 현재 트랜잭션 모드를 설정합니다. read uncommitted(read uncommitted), 쿼리 테이블 계정의 초기 값은
입니다. (2) 클라이언트 A의 트랜잭션이 제출되기 전에 다른 클라이언트 B를 열고 테이블 계정을 업데이트합니다.
(3) 이때 클라이언트 B의 트랜잭션이 아직 제출되지 않았더라도 클라이언트 A는 B의 업데이트된 데이터를 쿼리할 수 있습니다.
(4) 클라이언트 B의 트랜잭션이 어떤 이유로 중단되면 롤백하면 모든 작업이 취소됩니다. , 클라이언트 A가 쿼리한 데이터는 실제로 더티 데이터입니다.
(5) 클라이언트 A에서 업데이트 문을 실행합니다. 업데이트 계정에서 잔액 = 잔액 - 50을 설정합니다. 여기서 id =1, lilei의 잔액은 350이 되지 않았지만 실제로는 400. 이상하지 않습니까? 그렇게 생각한다면 너무 순진한 생각입니다. 다른 세션에서는 롤백됩니다. 이 문제는 읽기 커밋 격리 수준
을 사용할 수 있습니다. 2. 커밋된 읽기
(1) 클라이언트 A를 열고 현재 트랜잭션 모드를 커밋된 읽기(아직(Submit read))로 설정하고 초기 값을 쿼리합니다. 테이블 계정:
커밋 읽기 >> ââ'¬Å“ 클라이언트 B의 트랜잭션이 아직 제출되지 않았습니다. 클라이언트 A는 B의 업데이트된 데이터를 쿼리할 수 없으므로 더티 읽기 문제가 해결됩니다.
(4) 클라이언트 B의 트랜잭션이 제출됨
(5) 클라이언트 A가 이전 단계와 동일한 쿼리를 실행했지만 결과가 이전 단계와 일치하지 않아 반복 불가능 읽기 문제가 발생함 3. 반복 읽기 (1) 클라이언트 A를 열고 현재 트랜잭션 모드를 설정합니다. 반복 읽기를 위해 테이블 계정을 쿼리합니다. bone Up over in 클라이언트 A ââ'¬â€ (1) 쿼리:
유력한 .50에서 id = 1이면 잔액은 400-50=350이 되지 않으며, (2)단계에서 350을 사용하여 lilei의 잔액 값을 계산하므로 300이 됩니다. 데이터는 파괴되지 않습니다. 이것은 약간 마술적입니다. 아마도 그것은 mysql의 기능일 것입니다. dml을 수행할 때 테이블의 실제 데이터에 따라 데이터를 반복해서 읽을 수 있습니다
mysql> select * from account;
+------+--------+---------+
| id | name | balance |
+------+--------+---------+
| 1 | lilei | 400 |
| 2 | hanmei | 16000 |
| 3 | lucy | 2400 |
+------+--------+---------+
3 rows in set (0.00 sec)
mysql> update account set balance = balance - 50 where id = 1;
Query OK, 1 row affected (0.00 sec)
Rows matched: 1 Changed: 1 Warnings: 0
mysql> select * from account;
+------+--------+---------+
| id | name | balance |
+------+--------+---------+
| 1 | lilei | 300 |
| 2 | hanmei | 16000 |
| 3 | lucy | 2400 |
+------+--------+---------+
3 rows in set (0.00 sec)
(5) 클라이언트 A에서 트랜잭션을 제출합니다. 클라이언트 B에서 테이블 계정의 초기 값 (6)의 초기 값은 트랜잭션을 시작하고, 새로운 데이터를 추가하여 밸런스 필드 값이 600이고,이를 제출합니다. > 계산해보니 A고객님이 제출하신 후 잔액합계를 계산해보니 19300이 나왔습니다. B고객님의 600이 계산에 포함되었기 때문입니다
，站在客户的角度，客户是看不到客户端B的，它会觉得是天下掉馅饼了，多了600块，这就是幻读，站在开发者的角度，数据的 一致性并没有破坏。但是在应用程序中，我们得代码可能会把18700提交给用户了，如果你一定要避免这情况小概率状况的发生，那么就要采取下面要介绍的事务隔离级别“串行化”
mysql> select sum(balance) from account;
+--------------+
| sum(balance) |
+--------------+
| 18700 |
+--------------+
1 row in set (0.00 sec)
mysql> commit;
Query OK, 0 rows affected (0.00 sec)
mysql> select sum(balance) from account;
+--------------+
| sum(balance) |
+--------------+
| 19300 |
+--------------+
1 row in set (0.00 sec)
4.串行化
（1）打开一个客户端A，并设置当前事务模式为serializable，查询表account的初始值：
mysql> set session transaction isolation level serializable;
Query OK, 0 rows affected (0.00 sec)
mysql> start transaction;
Query OK, 0 rows affected (0.00 sec)
mysql> select * from account;
+------+--------+---------+
| id | name | balance |
+------+--------+---------+
| 1 | lilei | 10000 |
| 2 | hanmei | 10000 |
| 3 | lucy | 10000 |
| 4 | lily | 10000 |
+------+--------+---------+
4 rows in set (0.00 sec)
（2）打开一个客户端B，并设置当前事务模式为serializable，插入一条记录报错，表被锁了插入失败，mysql中事务隔离级别为serializable时会锁表，因此不会出现幻读的情况，这种隔离级别并发性极低，开发中很少会用到。
mysql> set session transaction isolation level serializable;
Query OK, 0 rows affected (0.00 sec)
mysql> start transaction;
Query OK, 0 rows affected (0.00 sec)
mysql> insert into account values(5,'tom',0);
ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction
补充：
1、SQL规范所规定的标准，不同的数据库具体的实现可能会有些差异
2、mysql中默认事务隔离级别是可重复读时并不会锁住读取到的行
3、事务隔离级别为读提交时，写数据只会锁住相应的行
4、事务隔离级别为可重复读时，如果有索引（包括主键索引）的时候，以索引列为条件更新数据，会存在间隙锁间隙锁、行锁、下一键锁的问题，从而锁住一些行；如果没有索引，更新数据时会锁住整张表。
5、事务隔离级别为串行化时，读写数据都会锁住整张表
6、隔离级别越高，越能保证数据的完整性和一致性，但是对并发性能的影响也越大，鱼和熊掌不可兼得啊。对于多数应用程序，可以优先考虑把数据库系统的隔离级别设为Read Committed，它能够避免脏读取，而且具有较好的并发性能。尽管它会导致不可重复读、幻读这些并发问题，在可能出现这类问题的个别场合，可以由应用程序采用悲观锁或乐观锁来控制。
相关推荐：《mysql教程》
