MySQL Workbench无法图形化分析死锁，仅能执行SHOW ENGINE INNODB STATUS获取原始日志；死锁图需依赖第三方工具解析，核心是提取事务ID、持有锁与等待锁关系，并结合业务逻辑定位根因。
MySQL Workbench 本身不提供死锁图形化分析功能，它无法直接加载或可视化 SHOW ENGINE INNODB STATUS 中的死锁信息。 你看到的“死锁图”其实是社区或第三方工具（如 pt-deadlock-logger、innodb-trx-graph 脚本）解析后的结果，Workbench 只能帮你查到原始死锁日志片段。
从 SHOW ENGINE INNODB STATUS 提取死锁原始信息
死锁分析的第一步永远是拿到准确、完整的死锁快照。Workbench 的 SQL 编辑器可以执行这条命令，但要注意：
- 它只返回最近一次死锁，且在下一次死锁发生前会被覆盖 —— 所以必须在死锁刚发生后立刻执行
- 输出中关键段落以
*** (1) TRANSACTION:和*** (2) TRANSACTION:开头，后面紧跟着每个事务持有的锁（HELD LOCKS）和等待的锁（WAITING FOR THIS LOCK TO BE GRANTED） - 注意
mysql tables in use和locked tables行，能看出是否涉及显式LOCK TABLES（这在现代应用中极少见，但会干扰 InnoDB 行锁逻辑） - 事务的
TRANSACTION ID和THREAD ID可用于关联performance_schema.threads或错误日志中的线程堆栈
为什么不能直接在 Workbench 里画出锁等待图
因为 Workbench 没有内置解析器去结构化提取以下关键关系：
- 哪个事务在哪个表的哪一行（
RECORD LOCKS space id X page no Y n bits X）上持有什么类型锁（X、S、INSERT_INTENTION等） - 哪个事务正在等待同一资源上的冲突锁
- 事务之间的等待链是否成环（即：T1 → T2 → T3 → T1）
这些信息散落在文本块中，需要正则匹配 + 语义理解。Workbench 的“Visual Explain”只作用于查询执行计划，对锁信息无感知。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
用 Python 脚本快速生成简易锁等待图（替代 Workbench 图形化）
如果你坚持要图形化，最轻量的方式是把 INNODB STATUS 输出保存为文本，用几行 Python 解析并生成 dot 格式，再用 Graphviz 渲染：
import re
text = open('innodb_status.txt').read()
# 提取事务ID、等待对象、持有对象（示例逻辑）
for m in re.finditer(r'\*\*\* \((\d+)\) TRANSACTION:\s+.*?TRANSACTION (\w+),.*?WAITING FOR THIS LOCK TO BE GRANTED:\s+(.*?)(?=\*\*\*|\Z)', text, re.S):
trx_id, waiting_on = m.group(2), m.group(3).strip()
# ……进一步提取 table_name 和 lock_mode
# 最终 print(f'{trx_id} -> {blocking_trx}') 到 dot 文件
真正实用的方案是配合 pt-deadlock-logger --run-time=30s 实时捕获，并写入数据库表，再用 Workbench 的图表向导做简单聚合（比如按 server、db、table 分组统计死锁次数）。
死锁分析真正的复杂点不在图形化，而在于还原业务上下文：同一事务里前后几条 SQL 是否存在非预期的锁升级（比如 UPDATE 扫描了全表二级索引）、是否混合使用了 SELECT ... FOR UPDATE 和普通 UPDATE、有没有触发隐式锁转换（如唯一键冲突转为间隙锁）。这些，任何图形工具都看不到，只能靠日志 + 应用代码交叉比对。
