跨事务边界本身不会直接引发死锁，死锁仅发生在同一时刻多个并发事务内部且满足循环等待条件；真正风险在于事务A提交前调用外部服务触发新事务B操作相同数据，导致隐式交叉加锁、锁序失控。
跨事务边界本身不会直接引发死锁——死锁只发生在**同一时刻多个并发事务内部**，且满足循环等待条件。所谓“跨事务边界”的误解，往往源于对事务生命周期、锁释放时机或应用层逻辑拆分的混淆。真正危险的是：事务A在提交前调用外部服务（如RPC、HTTP），而该服务内部又开启新事务B去操作相同数据，导致A和B实际形成隐式交叉加锁。这种场景下，锁顺序失控、持有时间拉长、隔离级别叠加，死锁概率陡增。
为什么触发器或存储过程容易放大死锁风险
触发器（尤其是 AFTER INSERT）和存储过程默认复用当前事务上下文，所有DML语句共享同一事务ID和锁集合。一旦其中执行了未按统一顺序访问的 UPDATE，就等同于在原事务里“偷偷”多加了一组锁。
- 常见错误：订单表
AFTER INSERT触发器去更新用户余额表，但业务代码中另一路逻辑是先更新余额表再插入订单——锁顺序天然冲突 - 更隐蔽的问题：触发器里用了
WHERE category_id = ?这类非主键条件，没走索引 → InnoDB 升级为间隙锁（Gap Lock）→ 锁范围不可控，极易与并发的单行更新形成死锁 - 解决方案不是禁用触发器，而是把锁行为显性化：所有跨表更新必须命中主键或唯一索引；统计类逻辑一律移出触发器，改由应用层异步处理
应用层调用外部服务时如何避免隐式事务嵌套
这是线上高频死锁源头：事务A中执行 UPDATE order SET status=1 后，立刻发起支付网关调用；网关回调时又开启事务B去更新同一笔订单的 pay_status。此时A未提交、B已加锁，二者互等。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 根本原则：事务内禁止任何可能触发数据库写操作的外部调用。支付、短信、日志落盘等都应挪到
COMMIT之后 - 若必须同步感知结果（如扣库存后立即通知风控），改用
SELECT ... FOR UPDATE预占资源，并在事务末尾用UPDATE原子更新状态，而非依赖回调 - 对已存在的“事务+RPC”老代码，可临时加分布式锁（如Redis锁）兜底，但只是过渡方案，不能替代事务重构
如何验证你的事务是否真的“边界清晰”
别信代码注释或开发自述，要看真实锁行为。最有效的方式是结合 SHOW ENGINE INNODB STATUS 和慢查询日志反推：
- 在高峰期抓取死锁日志，重点看
LATEST DETECTED DEADLOCK中的TRANSACTIONID 和对应SQL——如果发现多个事务的SQL来自不同模块（如“order_service”和“payment_callback”），基本确认存在跨边界问题 - 检查
information_schema.INNODB_TRX表，筛选TRX_STATE = 'LOCK WAIT'的记录，观察其TRX_STARTED时间是否远超正常SQL执行耗时（比如 >500ms），这说明事务被外部IO卡住 - 用
EXPLAIN FORMAT=JSON确认每条关键UPDATE是否走了索引；没走索引的语句，在RR隔离级别下会激活间隙锁，让“看似不相关的两行更新”意外卷入同一死锁环
最容易被忽略的一点：事务边界不是靠 BEGIN/COMMIT 语法定义的，而是由锁的实际持有范围决定的。哪怕你写了 START TRANSACTION 又立刻 COMMIT，只要中间有 SELECT ... FOR UPDATE 没配对 UPDATE，或者用了 LOCK IN SHARE MODE 后忘了释放，这个“空事务”依然会持续持有锁直到连接关闭。所以排查死锁，永远要从锁本身出发，而不是从代码缩进或函数命名出发。
