存储过程本身不直接引发死锁，死锁由其内部执行的UPDATE、DELETE、SELECT ... FOR UPDATE等语句触发；排查关键在于通过SHOW ENGINE INNODB STATUS\G获取LATEST DETECTED DEADLOCK中实际SQL文本，并与存储过程代码逐行比对定位语句行号。
存储过程本身不直接引发死锁，死锁发生在它内部执行的 UPDATE、DELETE、SELECT ... FOR UPDATE 等语句上。排查关键不是看“存储过程怎么写”，而是抓出它实际发出的 SQL 及其加锁行为。
怎么看存储过程里哪条 SQL 触发了死锁
别在存储过程代码里猜。死锁发生后，立刻执行：SHOW ENGINE INNODB STATUS\G
重点看输出里的 LATEST DETECTED DEADLOCK 段——它不会显示“来自哪个存储过程”，但会精确列出两个事务各自执行的完整 SQL 文本（含参数值展开后的形式）。你只要把这段 SQL 和你的存储过程体逐行比对，就能定位到具体语句行号。
常见误区：
• 存储过程用了 DECLARE CONTINUE HANDLER 捕获 1213 错误（Deadlock found），但没记录原始 SQL，导致日志里只剩“调用 p_transfer_money”这种无意义信息
• 在 CALL 外层事务中执行存储过程，结果死锁日志里显示的是外层事务的 SQL，而非存储过程内部语句（因为 InnoDB 记录的是当前活跃事务的最后一条执行语句）
- 确保存储过程内部每个 DML 语句都带明确的 WHERE 条件，避免隐式全表扫描加锁
- 如果过程包含循环更新（如
WHILE+UPDATE），检查每次迭代是否按相同顺序访问行（例如始终按id ASC） - 用
SELECT ... FOR UPDATE前，确认该查询走的是唯一索引或主键；否则可能升级为间隙锁，扩大冲突面
为什么开启 innodb_print_all_deadlocks 后还是找不到对应存储过程名
因为 InnoDB 日志只记录事务持有的锁、等待的锁、SQL 文本和线程 ID，**不记录存储过程名、函数名或调用栈**。日志里出现的 query id 和 MySQL thread id 是唯一可关联线索。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
实操建议：
• 在存储过程开头加日志：插入一条带 CONNECTION_ID() 和当前时间戳的审计记录到 debug_log 表
• 抓到死锁日志后，用其中的 MySQL thread id 去查 information_schema.PROCESSLIST，过滤出对应连接最近执行过的语句
• 云数据库（如阿里云 RDS）控制台的“SQL 审计”功能可回溯该线程 ID 的完整调用链，包括 CALL 语句和参数
-
innodb_print_all_deadlocks = ON必须配合log_error路径有写权限，否则日志静默丢弃 - 某些 MySQL 版本（如 5.7.20 之前）在存储过程中执行多条 DML 时，
SHOW ENGINE INNODB STATUS可能只显示最后一条，需靠全量日志补全
存储过程里用临时表或游标会增加死锁风险吗
会，但原因不是“用了游标”，而是游标遍历时的锁行为不可控。典型风险点：
• 游标声明为 SELECT ... FOR UPDATE，但 FETCH 循环中未及时 COMMIT，导致锁长时间持有
• 临时表（CREATE TEMPORARY TABLE）虽不参与死锁检测（因不走 InnoDB 锁机制），但如果它被用于 JOIN 主表更新，间接放大主表锁范围
更隐蔽的问题：
• 存储过程内嵌子查询引用了其他表，而该表正在被外部事务修改（例如触发器更新日志表），形成跨对象锁等待环
• 使用 GET DIAGNOSTICS 或异常处理块时，若内部有隐式事务（如写入系统表），可能干扰锁释放时机
- 避免在游标循环内做网络调用、文件读写等长耗时操作——锁持有时间越长，死锁概率指数上升
- 用
EXPLAIN FORMAT=tree检查存储过程内所有 SELECT 是否走了预期索引，防止因索引失效导致锁行数暴增 - 批量操作优先用单条
INSERT ... ON DUPLICATE KEY UPDATE替代游标逐行更新，减少锁竞争窗口
真正难排查的从来不是“哪条 SQL 报错”，而是“为什么这条 SQL 在这里会和其他事务形成循环等待”。必须把存储过程还原成它实际生成的执行流，再结合索引结构、事务边界和并发调用模式交叉验证——否则只修表面错误，下次换一行照样死锁。
