当 MySQL 事务 “杠上”，死锁就是这么来的！

一、背景

在多用户、多事务并发执行的数据库系统中，死锁是一种不可避免的现象。当两个或多个事务相互等待对方释放锁资源时，就会形成死锁，导致这些事务无法继续执行，进而影响数据库系统的正常运行。MySQL 作为一种广泛使用的关系型数据库管理系统，提供了一系列的死锁处理机制来检测和解决死锁问题。

二、死锁的基本概念

2.1 死锁的定义

死锁是指两个或多个事务在执行过程中，因争夺锁资源而造成的一种互相等待的现象，导致这些事务都无法继续执行下去。例如，事务 T1 持有锁 L1 并请求锁 L2，而事务 T2 持有锁 L2 并请求锁 L1，此时 T1 和 T2 就陷入了死锁状态。

2.2 死锁产生的必要条件

根据操作系统的原理，死锁的产生必须同时满足以下四个必要条件：

必要条件	描述
互斥条件	一个资源每次只能被一个事务使用。例如，在 MySQL 中，一个排他锁（X 锁）在同一时间只能被一个事务持有。
请求和保持条件	一个事务因请求资源而阻塞时，对已获得的其他资源保持不放。比如事务 T1 已经持有锁 L1，在请求锁 L2 时被阻塞，但仍然持有锁 L1。
不剥夺条件	事务已获得的资源，在未使用完之前，不能被其他事务强行剥夺，只能由该事务自己释放。
循环等待条件	在发生死锁时，必然存在一个事务 - 资源的循环链，即事务集合 {T0, T1, T2, …, Tn} 中的 T0 正在等待一个 T1 占用的资源；T1 正在等待 T2 占用的资源，……，Tn 正在等待已被 T0 占用的资源。

2.3 死锁在 MySQL 中的表现

当 MySQL 中发生死锁时，通常会抛出错误信息。例如，在客户端执行 SQL 语句时，可能会收到类似如下的错误：

代码语言：javascript代码运行次数：0运行复制

ERROR 1213 (40001): Deadlock found when trying to get lock; try restarting transaction

这表明在尝试获取锁时发现了死锁，需要重新启动事务。

三、MySQL 中的锁机制

3.1 锁的类型

MySQL 支持多种类型的锁，主要分为以下几类：

锁类型	描述
共享锁（S 锁）	允许事务读取一行数据，多个事务可以同时对同一行数据加共享锁。例如，事务 T1 和 T2 可以同时对某一行数据加共享锁进行读取操作。
排他锁（X 锁）	允许事务更新或删除一行数据，同一时间只能有一个事务对某一行数据加排他锁。如果事务 T1 对某一行数据加了排他锁，那么其他事务在 T1 释放该锁之前无法对该行数据加任何类型的锁。
意向锁	用于表示事务即将对某个对象加共享锁或排他锁。意向锁分为意向共享锁（IS 锁）和意向排他锁（IX 锁），主要用于提高锁的检测效率。

3.2 锁的粒度

MySQL 中的锁可以分为不同的粒度，从细到粗主要有以下几种：

锁粒度	描述
行级锁	锁定表中的某一行数据，粒度最细，并发度最高。例如，InnoDB 存储引擎支持行级锁，在高并发场景下可以有效减少锁冲突。
页级锁	锁定表中的一个数据页，粒度介于行级锁和表级锁之间。
表级锁	锁定整个表，粒度最粗，并发度最低。MyISAM 存储引擎只支持表级锁。

3.3 锁的使用场景

不同类型和粒度的锁适用于不同的应用场景：

共享锁：适用于多个事务需要同时读取同一数据的场景，如并发查询操作。

排他锁：适用于事务需要对数据进行更新或删除的场景，确保数据的一致性。

行级锁：适用于高并发的 OLTP（在线事务处理）系统，能够减少锁冲突，提高并发性能。

表级锁：适用于对表进行批量操作的场景，如全表更新或删除，能够提高操作效率。

四、MySQL 死锁的成因

4.1 事务执行顺序不当

事务执行顺序不当是导致死锁的常见原因之一。例如，有两个事务 T1 和 T2，它们的执行顺序如下：

事务 T1	事务 T2
1. 对记录 R1 加排他锁	1. 对记录 R2 加排他锁
2. 请求对记录 R2 加排他锁	2. 请求对记录 R1 加排他锁

在这种情况下，T1 持有 R1 的排他锁并请求 R2 的排他锁，而 T2 持有 R2 的排他锁并请求 R1 的排他锁，就会形成死锁。

4.2 锁的竞争激烈

当多个事务同时竞争同一资源的锁时，也容易引发死锁。例如，在一个高并发的系统中，多个事务同时对同一行数据进行更新操作，就可能导致锁的竞争激烈，从而增加死锁的发生概率。

4.3 事务持有锁的时间过长

如果事务持有锁的时间过长，会增加其他事务等待锁的时间，从而提高死锁的发生概率。例如，一个事务在执行复杂的查询或更新操作时，长时间持有锁，可能会导致其他事务在等待锁的过程中形成死锁。

4.4 索引使用不当

索引使用不当会影响 MySQL 的锁机制，从而导致死锁的发生。例如，如果没有为查询条件创建合适的索引，MySQL 可能会进行全表扫描，从而对整个表加锁，增加了锁的竞争和死锁的风险。

五、MySQL 死锁的检测机制

5.1 超时机制

MySQL 提供了超时机制来处理死锁问题。当一个事务等待锁的时间超过了设定的超时时间（由参数 innodb_lock_wait_timeout 控制，默认值为 50 秒），MySQL 会自动回滚该事务，并抛出死锁错误。

超时机制的优点是简单易用，不需要额外的检测开销。但缺点是不够精确，可能会误判一些正常的锁等待情况，并且在高并发场景下，可能会导致大量事务被回滚，影响系统性能。

5.2 等待图算法

InnoDB 存储引擎使用等待图算法来检测死锁。等待图是一个有向图，其中节点表示事务，边表示事务之间的锁等待关系。当一个事务 T1 等待另一个事务 T2 释放锁时，就会在等待图中添加一条从 T1 到 T2 的有向边。InnoDB 会定期检查等待图中是否存在循环，如果存在循环，则表示发生了死锁。一旦检测到死锁，InnoDB 会选择一个事务作为牺牲品进行回滚，以打破死锁。等待图算法的优点是能够精确地检测到死锁，但缺点是需要额外的计算开销，尤其是在高并发场景下，可能会影响系统性能。

5.3 死锁检测流程图

六、MySQL 死锁的解决策略

6.1 回滚牺牲品事务

当 MySQL 检测到死锁时，会选择一个事务作为牺牲品进行回滚。InnoDB 通常会选择回滚代价最小的事务，例如持有锁最少、执行时间最短的事务。

回滚牺牲品事务是一种简单有效的解决死锁的方法，但会导致该事务的操作全部失败，需要重新执行。因此，在应用程序中需要对这种情况进行处理，例如重试机制。

6.2 重试机制

在应用程序中实现重试机制是处理死锁的常用方法。当应用程序收到死锁错误时，可以捕获该错误并重新执行事务。通常会设置一个最大重试次数，避免无限重试。

使用 Python 和 MySQL Connector/Python 实现的简单重试机制示例：

代码语言：javascript代码运行次数：0运行复制

import mysql.connector
import time

MAX_RETRIES = 3

def execute_transaction():
    retries = 0
    while retries < MAX_RETRIES:
        try:
            # 连接到 MySQL 数据库
            cnx = mysql.connector.connect(user='user', password='password',
                                          host='127.0.0.1',
                                          database='test')
            cursor = cnx.cursor()

            # 开始事务
            cnx.start_transaction()

            # 执行 SQL 语句
            cursor.execute("UPDATE table_name SET column1 = 'value' WHERE id = 1")

            # 提交事务
            cnxmit()

            # 关闭连接
            cursor.close()
            cnx.close()
            print("Transaction executed successfully.")
            break
        except mysql.connector.Error as err:
            if err.errno == 1213:  # 死锁错误
                print(f"Deadlock detected. Retrying ({retries + 1}/{MAX_RETRIES})...")
                retries += 1
                time.sleep(1)  # 等待 1 秒后重试
            else:
                print(f"Error: {err}")
                break
    else:
        print("Max retries reached. Transaction failed.")

execute_transaction()

6.3 优化事务设计

优化事务设计可以减少死锁的发生概率。例如，尽量缩短事务的执行时间，减少事务持有锁的时间；按照相同的顺序访问资源，避免事务执行顺序不当导致的死锁。

6.4 调整锁的粒度

根据应用场景的不同，合理调整锁的粒度也可以减少死锁的发生。例如，在高并发场景下，尽量使用行级锁而不是表级锁，以减少锁的竞争。

七、MySQL 死锁的预防措施

7.1 合理设计事务

尽量缩短事务的执行时间，避免长时间持有锁。例如，将大事务拆分成多个小事务，减少锁的持有时间。

按照相同的顺序访问资源，避免事务执行顺序不当导致的死锁。例如，在多个事务中都按照记录的主键升序访问记录。

7.2 优化索引

为查询条件创建合适的索引可以减少锁的竞争和死锁的风险。例如，对于经常用于查询和更新的字段，创建索引可以提高查询效率，减少全表扫描的可能性。

7.3 控制并发度

通过调整数据库的参数或应用程序的并发控制策略，控制并发度，减少锁的竞争。例如，限制同时执行的事务数量，避免高并发场景下的锁冲突。

7.4 定期监控和分析

定期监控 MySQL 的死锁情况，分析死锁的原因和模式，及时采取措施进行优化。可以使用 MySQL 的日志文件（如错误日志、慢查询日志）和性能监控工具（如 MySQL Enterprise Monitor）来监控死锁情况。

八、案例分析

8.1 案例背景

某电商系统的订单处理模块在高并发场景下频繁出现死锁问题，影响了系统的正常运行。

8.2 问题分析

通过分析 MySQL 的错误日志和慢查询日志，发现死锁主要是由于事务执行顺序不当和锁的竞争激烈导致的。具体来说，在处理订单时，多个事务同时对订单表和库存表进行操作，并且没有按照相同的顺序访问资源，导致死锁的发生。

8.3 解决方案

优化事务设计：调整事务的执行顺序，确保所有事务都按照相同的顺序访问订单表和库存表。例如，先对订单表加锁，再对库存表加锁。

优化索引：为订单表和库存表的关键字段创建索引，提高查询效率，减少锁的竞争。

增加重试机制：在应用程序中增加重试机制，当收到死锁错误时，自动重试事务。

8.4 效果评估

经过优化后，系统的死锁问题得到了显著改善，订单处理模块的性能和稳定性得到了提高。

九、小结

随着数据库技术的不断发展，MySQL 的死锁处理机制也将不断完善。未来，可能会出现更加智能和高效的死锁检测和解决方法，例如基于机器学习的死锁预测和预防技术。同时，随着分布式数据库的广泛应用，分布式死锁的处理也将成为一个重要的研究方向。

本文参与 腾讯云自媒体同步曝光计划，分享自作者个人站点/博客。 原始发表：2025-04-06，如有侵权请联系 cloudcommunity@tencent 删除前往查看数据索引mysql高并发事务