Seata与MySQL死锁问题分析与解决实践

问题背景

在使用分布式事务框架Seata 1.8.0操作MySQL数据库时，开发人员遇到了一个棘手的死锁问题。具体表现为：两个并发事务在同一个方法中通过不同ID获取行锁时发生死锁，且死锁的SQL语句是由Seata自动生成的SELECT...FOR UPDATE查询。

问题现象

1. 死锁表现：两个事务分别执行：

   • 事务1：SELECT id FROM locator WHERE flag_deleted = 0 AND id IN (9792, 9752) FOR UPDATE
   • 事务2：SELECT id FROM locator WHERE flag_deleted = 0 AND id IN (116, 9753) FOR UPDATE

2. 异常信息：系统抛出org.springframework.dao.DeadlockLoserDataAccessException异常，提示"Deadlock found when trying to get lock"

3. 临时解决方案问题：尝试在本地事务外捕获异常并重试时，Seata报错"mysql release save point error"，提示"SAVEPOINT does not exist"

深入分析

死锁原因探究

通过分析MySQL的SHOW ENGINE INNODB STATUS输出，发现死锁的根本原因在于：

1. 索引使用异常：Seata生成的SELECT...FOR UPDATE语句本应使用主键索引(PRIMARY KEY)，但实际上却使用了唯一索引(UNIQUE KEY code)

2. 锁冲突机制：由于使用了非预期的索引，导致MySQL在加锁时产生了锁冲突，最终形成死锁环

3. 执行计划验证：通过EXPLAIN分析发现，当查询字段仅为id时，MySQL优化器错误地选择了code索引而非主键索引；而当增加查询字段(如name)后，执行计划恢复正常使用了主键索引

临时解决方案的问题

在尝试通过捕获异常并重试的临时解决方案时，出现的"SAVEPOINT does not exist"错误是由于：

1. Seata在执行SELECT...FOR UPDATE时会创建保存点(SAVEPOINT)
2. 当发生死锁时，MySQL会自动回滚事务，导致保存点失效
3. Seata仍尝试释放已不存在的保存点，从而抛出异常

解决方案

根本解决措施

1. 修复MySQL索引统计信息：

   • 执行ANALYZE TABLE locator命令更新表的统计信息
   • 确保MySQL优化器能够正确选择主键索引

2. 强制索引使用：

   • 在Seata配置中指定强制使用主键索引
   • 或者修改SQL模板，添加FORCE INDEX(PRIMARY)提示

3. 查询字段调整：

   • 在业务允许的情况下，增加查询字段数量，促使MySQL选择主键索引

临时解决方案优化

对于必须捕获死锁异常的场景：

1. 在捕获异常后，不应直接重试原事务
2. 应先确保当前事务完全回滚，再创建新事务执行重试
3. 或者考虑使用Spring的@Retryable注解实现更优雅的重试机制

经验总结

1. 分布式事务环境下的锁机制更为复杂：Seata的全局锁机制与MySQL行锁交互时，需要特别注意索引使用情况

2. MySQL优化器并非总是可靠：即使是最新版本的MySQL，优化器也可能做出非预期的执行计划选择

3. 全面的异常处理很重要：在分布式事务场景下，异常处理需要考虑事务状态、保存点等多方面因素

4. 监控与分析工具的价值：SHOW ENGINE INNODB STATUS和EXPLAIN是诊断数据库问题的有力工具

最佳实践建议

1. 定期对核心业务表执行ANALYZE TABLE维护
2. 在开发环境中对关键SQL进行执行计划验证
3. 为Seata的全局锁查询设计专门的索引策略
4. 实现完善的死锁检测与恢复机制
5. 在高并发场景下考虑使用乐观锁替代悲观锁

通过这次问题的分析与解决，我们不仅解决了具体的死锁问题，更深入理解了Seata与MySQL交互时的底层机制，为今后处理类似问题积累了宝贵经验。