作者：洪斌
爱可生南区负责人兼技术服务总监，MySQL ACE，善于数据库架构布局、故障诊断、性能优化剖析，实践经验丰盛，帮忙各行业客户解决 MySQL 技术问题，为金融、运营商、互联网等行业客户提供 MySQL 整体解决方案。
本文起源：转载自公众号 - 玩转 MySQL
* 爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。
你是否会常常遇到 MySQL hang 了而手足无措？面对繁冗的 callstack 信息如何能力疾速剖析出起因？
本文将通过一个案例，介绍如何疾速剖析这类问题的办法。
当咱们遇到 MySQL hang 的场景时，大概率是程序外部产生了 mutex 抵触造成的。这时咱们须要在重启服务前，先收集 callstack 信息。
pstack `pidof mysqld` > mysql_callstack留神：mysqld 须要蕴含符号表
有了 callstack 信息，咱们便能够开始进行剖析了。
剖析步骤
- 首先，在 callstack 日志筛选出每个线程调用 inline_mysql_mutex_lock 前的函数，以及对应的 mutex 代码地位，此处便是线程在期待的 mutex。
- 而后，从该函数向前遍历每个函数调用，寻找这些函数，看曾经胜利取得哪些 mutex。
这里我用脚本对日志进行格式化解决，将每个函数都映射到了 github 的代码地位，点击链接能够间接跳转，应用 Chrome 浏览器配合 sourcegraph 查看代码也很香。
- 最初，从日志中回溯每个上锁函数所对应的前端操作行为，并绘制一张对于线程持有和期待 mutex 的表格，便能直观的剖析出函数的抵触关系。
总结
因为 show binlog logs 操作、purge binlog 以及从读取 performance_schema 读取会话变量几个操作并行产生产生 mutex 抵触，导致无奈新建连贯申请。
- show binary logs，持有 LOCK_log，期待 LOCK_index
- binlog purge，持有 LOCK_index, 期待 LOCK_thd_data
- 读取 performance_schema.session_variables，持有 LOCK_thd_data, LOCK_global_system_variables, 期待 LOCK_log
- 新建连贯，期待 LOCK_global_system_variables
最终确认是 binlog_transaction_dependency_* 变量的读取须要获取 LOCK_log 锁，此处容易造成死锁，MySQL 5.7.25 修复了此问题。
脚本：https://gist.github.com/kevin…