事务就是要保证一组数据库操作,要么全部成功,要么全部失败。在MySQL中,事务支持是在引擎层实现的
ACID(Atomicity、Consistency、Isolation、Durability,即原子性、一致性、隔离性、持久性)
InnoDB里面每个事务有一个唯一的事务ID,叫作transaction id。它是在事务开始的时候向InnoDB的事务系统申请的,是按申请顺序严格递增的
隔离性与隔离级别
读未提交(read uncommitted) 一个事务还没提交时,它做的变更就能被别的事务看到
读提交(read committed)一个事务提交之后,它做的变更才会被其他事务看到,查询只承认在语句启动前就已经提交完成的数据
可重复读(repeatable read) 一个事务执行过程中看到的数据,总是跟这个事务在启动时看到的数据是一致的,未提交变更对其他事务也是不可见的,查询只承认在事务启动前就已经提交完成的数据
串行化(serializable )同一行记录,“写”会加“写锁”,“读”会加“读锁”。当出现读写锁冲突的时候,后访问的事务必须等前一个事务执行完成,才能继续执行
长事务和回滚日志
回滚日志: 在MySQL中,每条记录在更新的时候都会同时记录一条回滚操作。记录上的最新值,通过回滚操作,都可以得到前一个状态的值
在查询这条记录的时候,不同时刻启动的事务会有不同的read-view,要获取旧的视图,必须将当前值依次执行回滚操作得到
当没有事务再需要用到这些回滚日志时,就是当系统里没有比这个回滚日志更早的read-view的时候,回滚日志会被删除
长事务的影响系统里面会存在很老的事务视图,在这个事务提交之前数据库里面它可能用到的回滚记录都必须保留,这就会导致大量占用存储空间
set autocommit=0 这个命令会将这个线程的自动提交关掉,只执行一个select语句,这个事务就启动了,而且并不会自动提交。持续存在直到你主动执行commit 或 rollback 语句,或者断开连接
commit work and chain 提交事务并自动启动下一个事务,省去了再次执行begin语句的开销
查找持续时间超过60s的事务
select * from information_schema.innodb_trx where TIME_TO_SEC(timediff(now(),trx_started))>60
SET MAX_EXECUTION_TIME
命令,来控制每个语句执行的最长时间,避免单个语句意外执行太长时间
监控 information_schema.Innodb_trx表,设置长事务阈值,超过就报警/或者kill
设置innodb_undo_tablespaces
(默认值为0,表示不独立设置undo的tablespace,默认记录到ibdata系统表空间中,否则,则在undo目录下创建这么多个undo文件)成2(或更大的值),如果真的出现大事务导致回滚段过大方便清理
可重复读和MVCC
MVCC 数据表中的一行记录,其实可能有多个版本(row),每个版本有自己的row trx_id,旧版本需要根据当前版本和undo log计算出来
begin/start transaction 命令并不是一个事务的起点,在执行到它们之后的第一个操作InnoDB表的语句(第一个快照读语句),事务才真正启动。如果想要马上启动一个事务,可以使用start transaction with consistent snapshot1
InnoDB为每个事务构造了一个数组,用来保存这个事务启动瞬间,当前正在“活跃”的所有事务ID。“活跃”指的就是,启动了但还没提交,数组里面事务ID的最小值记为低水位,当前系统里面已经创建过的事务ID的最大值加1记为高水位。
这个视图数组和高水位,就组成了当前事务的一致性视图(read-view),只有版本已提交,而且是在视图创建前提交的才可见
更新数据都是先读后写的,而这个读,只能读当前的值,称为“当前读”(current read) set k=k+1会拿最新的值做更新,更新后的trx_id是自己的更新,可以直接使用,如果当前的记录的行锁被其他事务占用的话,就需要进入锁等待