MySQL InnoDB 死锁问题分析与解决

2024-12-16 11:08:57

在MySQL InnoDB存储引擎中，死锁是一种常见的问题，它会导致事务无法完成，进而影响应用的正常运行。本文将针对MySQL 5.7版本中出现的死锁问题，特别是不同行上的 SELECT 和 UPDATE 操作之间的死锁进行深入分析，并提供一系列解决方案和预防措施。

死锁现象剖析

死锁是指两个或多个事务在执行过程中，因争夺资源而相互等待，导致所有事务都无法继续执行的情况。上述案例中，一个事务正在执行 UPDATE 操作，试图获取 table1 表中 column6=0 的行的排他锁（X锁），而另一个事务正在执行 SELECT 操作，试图获取 table1 表中 column6=1 的行的共享锁（S锁）。虽然这两个操作作用于不同的行，但由于InnoDB的锁机制以及可能存在的索引扫描等因素，依然可能导致死锁。

从提供的日志信息可以看出：

事务 (1) 正在尝试更新 column6=0 的记录，并已持有部分行的 X 锁，但正在等待获取另一行的 X 锁。
事务 (2) 正在尝试从 table1 创建临时表，涉及到 SELECT DISTINCT 操作，并持有 column6=1 的行的 S 锁，但正在等待获取另一行的 S 锁，而这行 S 锁恰好被事务 (1) 占用并等待释放 X 锁，最终导致死锁。

需要注意的是，即使 SELECT 和 UPDATE 操作作用于不同的数据行，但如果它们在扫描索引或数据时访问顺序不一致，仍然可能发生死锁。例如，事务 (1) 按照主键升序扫描，而事务 (2) 按照索引降序扫描，就可能导致它们在某个时间点互相等待对方释放锁。

解决死锁的方案

解决死锁问题的关键在于打破事务间的循环等待。以下是一些常用的解决方案和预防措施：

优化事务设计，尽量缩短事务的持有锁的时间 : 核心思想就是尽快的提交或者回滚事务，减少事务的执行时间，从根本上降低死锁发生的概率。具体可以通过以下几个方式来实现:
- 避免长事务 : 将大事务拆分为小事务，减少事务中执行的操作数量，避免事务长时间占用锁资源。
- 及早释放锁 : 对于不需要持有锁的操作，尽量在事务的早期完成，释放锁资源，例如一些与核心数据无关的查询或者操作。
- 减少锁的范围 : 避免全表扫描或者更新，尽可能的使用索引来缩小锁的范围。确保所有的查询都使用了必要的where条件和索引,并且尽量使用覆盖索引。
- 更新/插入/删除之前检索数据 : 考虑在 UPDATE 或者 DELETE 语句之前，预先通过 SELECT 语句检索需要操作的数据。 SELECT 不需要获取排他锁，可以减少事务的阻塞时间。例如：
```
    SELECT column1, column2, column3 from table1 where column6=0 and column3='xx' and column4 ='xx' and column5='xx' FOR SHARE; -- 首先获取共享锁，检查数据
    --  其它操作
    UPDATE table1 SET column1=UTC_TIMESTAMP(), column2='KC_AUTO', column3 = 'some random value' WHERE column6=0 and column3 = 'xx' AND column4 = 'xx' AND column5 = 'xx';
```
操作步骤:
1. 分析现有事务的逻辑，识别可以拆分或提前完成的操作。
2. 修改代码，将事务拆分为更小的单元，或者将不需要持有锁的操作移到事务的早期。
3. 重新测试，验证死锁问题是否得到解决，同时关注事务的执行时间和系统性能。
调整事务隔离级别 : MySQL 的事务隔离级别有多个级别，由低到高分别是读未提交（Read Uncommitted）、读已提交（Read Committed）、可重复读（Repeatable Read）和串行化（Serializable）。事务隔离级别越高，数据一致性越好，但并发性能越低，发生死锁的可能性也越大。

当前MySQL版本（5.7）的默认隔离级别为可重复读，虽然避免了脏读和不可重复读，但可能由于间隙锁等机制导致死锁。如果业务允许，可以考虑降低事务隔离级别为读已提交来减少死锁：
```
--  查看当前会话的事务隔离级别
SELECT @@SESSION.tx_isolation;

--  设置当前会话的事务隔离级别为读已提交
SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED;
--  或者
SET TRANSACTION ISOLATION LEVEL READ COMMITTED;

--  修改 MySql 配置文件 my.cnf  或者 my.ini 永久修改数据库默认的隔离级别
--  在 [mysqld] 块中添加如下配置
[mysqld]
transaction-isolation = READ-COMMITTED
--  重启MySQL服务使配置生效
```
操作步骤:
1. 评估降低事务隔离级别对业务数据一致性的影响。
2. 如果确认可以降低隔离级别，修改应用程序的配置或在事务开始时设置隔离级别。
3. 测试在新的隔离级别下，死锁问题是否得到解决，并密切关注数据一致性。
调整SQL语句的执行顺序

确保对同一张表进行操作的多个事务，访问数据的顺序尽量保持一致，避免交叉访问导致死锁。比如都按照主键的升序访问：
```
-- 事务1:
SELECT ... FROM table1 WHERE column6 = 0 ORDER BY column_id ASC;
UPDATE table1 ... WHERE column6 = 0 AND column_id > 'some_id';

-- 事务2:
CREATE TEMPORARY TABLE t_ss 
SELECT DISTINCT column0 FROM table1 SS
JOIN table2 sa ON SS.column3 = sa.column3 AND sa.column7 = SS.column7 AND SS.column4 = sa.column4
WHERE sa.column1 >= (upToDateTime - INTERVAL 3 DAY) AND column10 IS NOT NULL AND SS.column6 = 1 ORDER BY column_id ASC limit RecordsLimit;
```
操作步骤:
1. 分析死锁日志，找出涉及死锁的 SQL 语句。
2. 识别 SQL 语句中可能导致死锁的数据访问模式。
3. 调整 SQL 语句的 WHERE 条件、ORDER BY 子句等，使不同事务的访问顺序尽可能一致。
4. 如果涉及多个表的关联操作，确保关联顺序和访问顺序的一致性。
使用 LOCK TABLES 或 GET_LOCK() 函数

这种方法适用于对并发要求不高，但数据一致性要求非常高的场景。通过显式地锁定表或使用用户锁，可以避免并发事务之间的相互干扰，从而解决死锁。

LOCK TABLES 方案：
- 原理 : 在事务开始前，使用 LOCK TABLES 语句锁定需要访问的表，可以是共享锁（READ）或排他锁（WRITE）。一旦锁定，其他事务就无法访问这些表，直到当前事务释放锁。
- 优点 : 简单直接，能够有效避免死锁。
- 缺点 : 降低了并发性能，容易导致阻塞，影响系统吞吐量。
```
-- 事务1:
LOCK TABLES table1 WRITE;
UPDATE table1 SET column1=UTC_TIMESTAMP(), column2='KC_AUTO', column3 = 'some random value' WHERE column6=0 and column3 = 'xx' AND column4 = 'xx' AND column5 = 'xx';
UNLOCK TABLES;

-- 事务2:
LOCK TABLES table1 READ, table2 READ;
CREATE TEMPORARY TABLE t_ss
    SELECT distinct column0
    FROM table1 SS
             JOIN table2 sa
                  ON SS.column3 = sa.column3 and sa.column7 = SS.column7 and SS.column4 = sa.column4
    where sa.column1 >= (upToDateTime - INTERVAL 3 DAY)
      AND column10 is not null
      and SS.column6 = 1
    limit RecordsLimit;
UNLOCK TABLES;
```
操作步骤:
1. 确定需要锁定的表和锁的类型。
2. 在事务开始前，使用 LOCK TABLES 语句锁定表。
3. 执行事务中的 SQL 语句。
4. 事务完成后，使用 UNLOCK TABLES 语句释放锁。