如何查看mysql的锁信息

方法1：利用 metadata_locks 视图

此方法仅适用于 MySQL 5.7 以上版本，该版本 performance_schema 新增了 metadata_locks，如果上锁前启用了元数据锁的探针（默认是未启用的），可以比较容易的定位全局锁会话。

方法2：利用 events_statements_history 视图此方法适用于 MySQL 5.6 以上版本，启用 performance_schema.eventsstatements_history（5.6 默认未启用，5.7 默认启用），该表会 SQL 历史记录执行，如果请求太多，会自动清理早期的信息，有可能将上锁会话的信息清理掉。

方法3：利用 gdb 工具如果上述两种都用不了或者没来得及启用，可以尝试第三种方法。利用 gdb 找到所有线程信息，查看每个线程中持有全局锁对象，输出对应的会话 ID，为了便于快速定位，我写成了脚本形式。也可以使用 gdb 交互模式，但 attach mysql 进程后 mysql 会完全 hang 住，读请求也会受到影响，不建议使用交互模式。

方法4：show processlist

如果备份程序使用的特定用户执行备份，如果是 root 用户备份，那 time 值越大的是持锁会话的概率越大，如果业务也用 root 访问，重点是 state 和 info 为空的，这里有个小技巧可以快速筛选，筛选后尝试 kill 对应 ID，再观察是否还有 wait global read lock 状态的会话。

方法5：重启试试！

以下五种方法可以快速定位全局锁的位置，仅供参考。

方法1：利用 metadata_locks 视图

此方法仅适用于 MySQL 5.7 以上版本，该版本 performance_schema 新增了 metadata_locks，如果上锁前启用了元数据锁的探针（默认是未启用的），可以比较容易的定位全局锁会话。

方法2：利用 events_statements_history 视图此方法适用于 MySQL 5.6 以上版本，启用 performance_schema.eventsstatements_history（5.6 默认未启用，5.7 默认启用），该表会 SQL 历史记录执行，如果请求太多，会自动清理早期的信息，有可能将上锁会话的信息清理掉。

方法3：利用 gdb 工具如果上述两种都用不了或者没来得及启用，可以尝试第三种方法。利用 gdb 找到所有线程信息，查看每个线程中持有全局锁对象，输出对应的会话 ID，为了便于快速定位，我写成了脚本形式。也可以使用 gdb 交互模式，但 attach mysql 进程后 mysql 会完全 hang 住，读请求也会受到影响，不建议使用交互模式。

方法4：show processlist

如果备份程序使用的特定用户执行备份，如果是 root 用户备份，那 time 值越大的是持锁会话的概率越大，如果业务也用 root 访问，重点是 state 和 info 为空的，这里有个小技巧可以快速筛选，筛选后尝试 kill 对应 ID，再观察是否还有 wait global read lock 状态的会话。

方法5：重启试试！

给你个过来人的建议。两个方式入手。

1、利用他。尽可能从大模块开始，用你的代码，去调用他。这是从功能特性角度，去理解各个模块的作用。这非常容易加深你对应用它的理解。

2、在代码中插入LOG，检测代码运行流程。

如果你只是静态的看代码，这个不现实的。

如果你想看一部分代码。首先你要想办法让这套代码RUN起来，如果你使用任何方式都无法让这段代码运行，我只能说，这段代码没有存在价值。为什么在里面，当然更大的可能是，你没找到开启它的方法。

动态分析法，是门学问。包括对运行态才出现BUG的系统进行DEBUG，当然不是GDB或者VC的F5模式。不过貌似学校没有这类教学。很工程的东西。我也只是经验所得。没有系统的理论化。

例如一套系统，你在不改代码的情况下，要能找到问题。甚至不能加LOG代码，只能通过反馈判断。不是不可能的。甚至有时必须这么做。

---