MySQL高级开发 – 行锁（InnoDB）

标签（空格分隔）： MySQL

• MySQL高级开发 行锁InnoDB

行锁使用场景

偏向InnoDB存储引擎，开销大，加锁慢；会出现死锁，锁定粒度最小，发生锁冲突的概率最小，并发度最高.

和表锁对比

Innodb存储引擎实现了行级锁定，虽然在锁定机会的实现方面所带来的性能损耗可能比表级锁定会要更高一些，但是在整体并发处理能力方面远远优于MyISAM的表级锁定的，当系统并发量较高的时候，Innodb的整体性能MyISAM相比会有比较明显的优势。
但是Innodb的行级锁定同样也有其脆弱的一面，当我们使用不当的时候，可能会让Innodb的整体性能表现不仅不能比MyISAM高，设置可能更差

如何分析行锁定

通过检查InnoDB_row_lock状态变量来分析系统的行锁的争夺情况

show status like 'Innodb_row_lock%';

查询结果如下：

Innodb_row_lock_current_waits #当前正在等待锁定的数量
Innodb_row_lock_time #从系统启动到现在锁定的总时长
Innodb_row_lock_time_avg #每次锁定等待平均时长
Innodb_row_lock_time_max #最大等待时长
Innodb_row_lock_waits #总共等待次数

可以使用show profile进行分析

间隙锁

当我们用范围条件而不是相等条件检索数据，并请求共享或排他锁时，InnoDB会给符合条件的已有数据记录的索引项加锁，对于键值在条件范围内胆并不存在的记录，叫做“间隙(GAP)”
Innodb也会对这个“间隙”加锁，这种锁机制就是所谓的间隙锁

间隙锁的危害

因为Query执行过程中通过范围查找的话，他会锁定整个范围内的所有键值，即使这个键值并不存在，间隙锁有一个致命的弱点，就是当锁定一个范围值之后，即使某些不存在的键值也会被无辜的锁定，而造成在锁定的时候无法插入值范围内的任何数据，在某些场景下这可能会对性能在成很大的问题

锁优化建议

1. 尽可能让所有数据检索都通过索引来完成，避免无索引行锁升级为表锁
2. 合理设计索引，经理缩小锁的范围
3. 尽可能较少检索条件，避免间隙锁
4. 尽量控制事务大小，减少锁定资源量和时间长度
5. 尽可能低级别事务隔离