Mysql一分钟定位 Next-Key Lock，你需要几分

查看连接信息 show processlistmysql 非企业版本只支持一个线程一个链接查看线程模型 show variables like 'thread_handling'【 事务提交策略】
有两个隐藏事务提交时间点需要注意，第一个是 autocommit=1 Mysql session 级别的自动提交变量，所有 ORM 框架中的事务提交控制都会受到这个字段影响，默认情况下当前语句会自动提交，但是如果是显示 begin transaction 开启事务需要自行手动提交。有些时候 ORM 框架会根据一些设置或者策略，将 autocommit 设置为0。第二个就是，DDL操作前都会隐式提交当前事务，有些脚本将DML和DDL混合在一起使用，这样会有一致性问题。DDL会自动提交当前事务。因为DDL在5.7之前都是不支持事务原则操作的。（Mysql8.0已经支持DDL事务性）Next-Key Lock 只发生在 RR（REPEATABLE-READ） 隔离级别下。Mysql 有很多类型对种锁，表锁、record lock、gap lock、意向共享/排他锁、插入意向锁、元数据锁、Auto_Incr自增锁，排除掉 元数据锁、Auto_Incr自增锁 之后，剩下的锁组合使用最多的就是在RR隔离级别下。RR隔离级别是默认事务隔离级别，也是Mysql的强项之一，在RR隔离级别下事务有最大的吞吐量，而且不会出现幻读问题。Next-Key Lock 就是为了解决这个问题，简单讲 record lock+gap lock 就是 Next-Key Lock。_幻读_的根本问题就是出现在记录的边界值上，比如我们统计年龄大于30岁的人数：select count(1) peoples where age>30 这个语句有可能每次查询得到的结果集都是不一样的，因为只要符合 age>30 的记录进到我们的 peoples 表中就会被查询条件命中。所以要想解决幻读不仅不允许记录的空隙被插入记录外，还要防止两遍记录被修改，因为如果前后两条记录被修改了那区间就会变大，就会有幻读出现。我们看个例子。为了方便调试，将 innodb 获取锁的超时时间调大点 开启两个会话。show processlist 找到连接的id。select * from information_schema.innodb_trx G 查看事务执行情况。457240 事开发云主机域名务状态是 LOCK WAIT 在等待锁，457239事务状态是 RUNNING执行中，正在等待事务提交。select * from information_schema.innodb_locks G 查看锁的占用情况。innodb_locks 表包含了已经获取到的锁信息和请求锁的信息。lock_index字段表示锁走的索引，record锁都是基于索引完成。根据上面事务457240状态是获取锁，lock_data | 35, 7，表示请求的数据。而事务457239占用了当前X锁。select * from information_schema.innodb_lock_waits 查看锁等待信息。457240 事务需要获取131:4:4锁，457239 事务占用了131:4:4锁。MySQL thread id 5 正在准备上插入意向锁，插入意向锁本质上是加间隙锁，是为了保证最大并发插入，不相关的行插入不受到互斥。thread id 5 需要保证在插入前加上间隙锁，主要是防止并发插入带来的一致性问题。session 5 和 session 8 都没有操作到 id=3，age=35的记录，但是却被X+Gap Lock 锁住，只有这样才能解决幻读问题。作者：王清培（趣头条 Tech Leader）

相关推荐: xtrabackup学习笔记

wget https://www.percona.com/downloads/XtraBackup/Percona-XtraBackup-2.4.7/binary/tarball/percona-xtrabackup-2.4.7-Linux-x86_64.ta…