[MYSQL]事务的隔离

隔离级别说明&原理

隔离级别

	说明	原理
读未提交	可以读到别的事务没提交的数据	每次都建一个读视图
读已提交	只能读到别的事务已提交的数据	每次sql执行的时候，创建读视图
可重复读	事务启动时读到的数据和事务执行中的数据是一致的	事务启动的时候创建视图
串行	一个事务执行时 别的事务不能执行。 写会加写锁，读会加读锁	考读写锁互斥

 

具体隔离方式

不同事务启动的时候，会有不同的read-view，在不同的视图里面 同一条记录可能会有多个值，这个就是MVCC。就是隔离实现的关键

如底部图：一个字段值由 1->2->3->4

每个视图也会对应一个回滚段，undo被删除的时机：当没有视图在它之前。所以长事务少用，注意及时commit/rollback

 

如何避免长事务的几个注意点

auto_commit 注意设置成1

减少不必要的只读事务

控制执行时长，设置 max_execution_time

 

相关命令

长事务
select * from information_schema.innodb_trx where TIME_TO_SEC(timediff(now(),trx_started))>60

隔离级别查看

show variables like 'transaction_isolation'; （老版本的是这个tx_isolation）

 

 

插入一段别人大白话描述的 注意长事务的弊端 （会导致回滚日志特别大）

在可重复读的隔离级别下，如何理解**当系统里没有比这个回滚日志更早的 read-view 的时候**，这个回滚日志就会被删除？

这也是**尽量不要使用长事务**的主要原因。

比如，在某个时刻（今天上午9:00）开启了一个事务A（对于可重复读隔离级别，此时一个视图read-view A也创建了），这是一个很长的事务……

事务A在今天上午9:20的时候，查询了一个记录R1的一个字段f1的值为1……

今天上午9:25的时候，一个事务B（随之而来的read-view B）也被开启了，它更新了R1.f1的值为2（同时也创建了一个由2到1的回滚日志），这是一个短事务，事务随后就被commit了。

今天上午9:30的时候，一个事务C（随之而来的read-view C）也被开启了，它更新了R1.f1的值为3（同时也创建了一个由3到2的回滚日志），这是一个短事务，事务随后就被commit了。

……

到了下午3:00了，长事务A还没有commit，为了保证事务在执行期间看到的数据在前后必须是一致的，那些老的事务视图、回滚日志就必须存在了，这就占用了大量的存储空间。

源于此，我们应该尽量不要使用长事务。