页面简洁的导航网站,it网站建设方案,网站开发保密协议书,龙华附近网站建设公司以下五种方法可以快速定位全局锁的位置#xff0c;仅供参考。方法1#xff1a;利用 metadata_locks 视图此方法仅适用于 MySQL 5.7 以上版本#xff0c;该版本 performance_schema 新增了 metadata_locks#xff0c;如果上锁前启用了元数据锁的探针(默认是未启用的)#x…以下五种方法可以快速定位全局锁的位置仅供参考。方法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 住读请求也会受到影响不建议使用交互模式。方法4show processlist如果备份程序使用的特定用户执行备份如果是 root 用户备份那 time 值越大的是持锁会话的概率越大如果业务也用 root 访问重点是 state 和 info 为空的这里有个小技巧可以快速筛选筛选后尝试 kill 对应 ID再观察是否还有 wait global read lock 状态的会话。方法5重启试试
