开发者学堂课程【MySQL 高级应用 - 索引和锁：行锁总结】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/598/detail/8639
行锁总结
目录：
一、案例结论
二、行锁定的分析
三、优化建议
一、案例结论
Innodb 存储引擎由于实现了行级锁定（存储引擎和锁的行为方式），虽然在锁定机制的实现方面所带来的性能损耗可能比表级锁定会要更高一些， 但是在整体并发处理能力方面要远远优于 MyISAM 的表级锁定的。
当系统并发量较高的时候，因为 innodb 的高并发，使得 Innodb 的整体性当与 MyISAM 进行比较时，前者体现出了较为明显的优势。
但是， Innodb 的行级锁定同样存在其脆弱的一面，当使用不当时，可能会让Innodb 的整体性能表现不仅不能比 MyISAM 高甚至可能会更差，较为明显具有特征的，例如行锁变表锁造成走向了得不偿失的地步。
二、行锁定的分析
通过检查 InnoDBrow_lock 状态变量来分析系统上的行锁的争夺情况
1.对各个状态的说明
mysql>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:
系统启动后到现在总共等待的次数;
对于这5个状态变量，比较重要的如下
Innodb_row_lock_time_avg (等待平均时长)，
Innodb_row_lock_waits (等待总次数)
Innodb_row_lock_time (等待总时长)
尤其是当等待次数很高，而且每次等待时长也不小的时候，需要分析系统中为什么会有如此多的等待，然后根据分析结果着手指定优化计划。
在 mysq 出错的情况下，有可能是客户端连接工具的问题。例如 session-3重连后便恢复正常。
诸如 mysq 一类的客户端工具更改配置参数后，最好重启重连系统，此为最为保险的方法。
而当部分工具更改完毕后仍为原样或缓存、保存特定关系，前一个方法无法起到作用则可以使用新开窗口的方式进行连接。
2.实例
session-1
mysql>show status like 'innodb_row_lock%';
//鼠标右键操作
+-------------------------------------------+-----------+
| Variable_name | 0 |
+-------------------------------------------+-----------+
|Innodb_row_lock_current_waits | 72038 |
|Innodb_row_lock_time | 18009 |
|Innodb_row_lock_time_avg | 29740 |
|Innodb_ row_lock_waits | 4 |
+-------------------------------------------+-----------+
5 rows in set (0.00 sec)
前三列为时间类，当锁定时间越多，则时间花费越长。由上述实例结果可得，当前无锁，接下来分别为锁定总时间长度；等待所花平均时间；最长的一次等待时间；启动后到现在总共等待的时间。
其中，最为重要的部分为等待锁定的数量与启动后到现在总共等待的时间。
三、优化建议
（1）尽可能让所有数据检索都通过索引来完成，避免无索引行锁升级为表锁。例如 varchar 类型必须添加单引号。
（2）合理设计索引，尽量缩小锁的范围尽可能较少检索条件，避免间隙锁。例如写范围查询时需要时刻注意间隙锁所带来的某些负面危害。
（3）尽量控制事务大小，减少锁定资源量和时间长度
（4）尽可能低级别事务隔离
