MySQL死锁问题解析与Java自动重启机制优化

1. 死锁问题的本质与MySQL的应对机制

MySQL死锁问题一直是Java开发者最头疼的数据库问题之一。当多个事务同时竞争相同的资源时，就可能出现死锁情况——事务A持有资源1等待资源2，而事务B持有资源2等待资源1，两者互相等待，形成死循环。

MySQL的默认处理方式是：检测到死锁后，自动选择其中一个事务作为牺牲者(victim)进行回滚，让另一个事务能够继续执行。这个机制看似合理，但在实际生产环境中却可能引发一系列连锁反应：

• 被回滚的事务需要重新执行
• 高并发场景下可能频繁触发死锁
• 应用层需要处理大量重试逻辑
• 系统整体吞吐量下降

2. 事务自动重启机制的实现原理

2.1 MySQL死锁检测机制

MySQL使用等待图(wait-for graph)算法来检测死锁。当检测到死锁时，InnoDB引擎会：

1. 计算每个事务的权重(基于修改的行数、事务年龄等)
2. 选择权重较小的事务作为牺牲者
3. 回滚该事务并释放其持有的锁
4. 向客户端返回1213错误码(Deadlock found)

2.2 自动重启的常见实现方案

Java开发者通常采用以下几种方式实现事务自动重启：

java复制// 方案1：基于Spring的@Retryable注解
@Retryable(value = {DeadlockLoserDataAccessException.class}, 
           maxAttempts = 3, backoff = @Backoff(delay = 100))
public void updateOrder(Order order) {
    // 业务逻辑
}

// 方案2：编程式重试
public void processWithRetry() {
    int retryCount = 0;
    while (retryCount < MAX_RETRY) {
        try {
            transactionTemplate.execute(status -> {
                // 业务逻辑
                return null;
            });
            break;