MySQL中锁的种类有哪些？如何避免死锁？-mysql教程-PHP中文网

MySQL通过共享锁和排他锁等机制保证数据一致性，避免死锁需确保事务以一致顺序访问资源并缩短事务周期。

mysql中锁的种类有哪些？如何避免死锁？

MySQL中的锁机制是确保数据完整性和并发性的核心，它种类繁多，理解这些锁的工作原理是优化数据库性能、避免死锁的关键。简单来说，锁主要分为共享锁（S锁，用于读操作）和排他锁（X锁，用于写操作），此外还有意向锁、记录锁、间隙锁、Next-Key锁等更细致的分类。至于死锁，它本质上是资源循环依赖的产物，要避免它，最核心的策略是确保事务以一致的顺序访问和锁定资源，并尽量缩短事务的持续时间。

解决方案

要深入理解MySQL的锁并有效避免死锁，我们需要从两个层面着手：一是全面认识MySQL（特别是InnoDB存储引擎）中各种锁的类型及其作用；二是针对性地采取预防和处理死锁的策略。

MySQL中锁的种类：

共享锁（Shared Locks, S锁）与排他锁（Exclusive Locks, X锁）
- S锁（读锁）：允许事务读取一行数据。多个事务可以同时持有同一行数据的S锁，因为读取操作通常不会相互干扰。
- X锁（写锁）：允许事务更新或删除一行数据。当一个事务持有一行数据的X锁时，其他事务不能再获取该行的S锁或X锁，确保数据修改的原子性和隔离性。
意向锁（Intention Locks, IS/IX锁）
- 这是表级别的锁，用于指示事务即将对表中的某些行加S锁或X锁。
- IS锁（Intention Shared Lock）：事务打算在表中的某些行上设置S锁。
- IX锁（Intention Exclusive Lock）：事务打算在表中的某些行上设置X锁。
- 意向锁的存在是为了提高效率，当一个事务想要对整张表加S锁或X锁时，它不需要检查每一行是否有行锁，只需检查表上是否有意向锁即可。
记录锁（Record Locks）
- 这是最基本的行锁，锁定的是索引中的一条记录。如果表没有定义任何索引，InnoDB会创建一个隐藏的聚簇索引，并使用它来锁定记录。
间隙锁（Gap Locks）
- 锁定的是索引记录之间的“间隙”，或者第一个索引记录之前的间隙，或者最后一个索引记录之后的间隙。它的主要目的是防止其他事务在这些间隙中插入新的记录，从而解决幻读问题（在Repeatable Read隔离级别下）。
Next-Key Locks
- 这是InnoDB在Repeatable Read隔离级别下默认的行锁类型。它结合了记录锁和间隙锁的特性，锁定索引记录本身以及它前面的间隙。例如，如果一个索引包含值10, 20, 30，Next-Key锁可能会锁定(10, 20]这个区间，包括20这条记录。
插入意向锁（Insert Intention Locks）
- 在插入新记录之前，事务会在插入位置（一个间隙）设置一个插入意向锁。这个锁是特殊的间隙锁，多个事务可以在同一个间隙内持有插入意向锁，只要它们插入的记录不冲突。
自增锁（AUTO-INC Locks）
- 这是一种特殊的表级锁，用于处理
```
AUTO_INCREMENT
```
  登录后复制
  列的并发插入。它确保每次插入都能获得唯一的、连续的自增值。

如何避免死锁：

死锁是两个或多个事务在相互等待对方释放资源时发生的一种僵局。InnoDB的死锁检测机制会自动回滚其中一个事务（通常是成本较低的那个），但这会导致事务失败，影响用户体验。因此，预防死锁比处理死锁更为重要。

保持一致的锁定顺序： 这是避免死锁最有效、最核心的策略。如果所有事务都以相同的顺序访问和锁定多个资源（例如，总是先锁定表A的行，再锁定表B的行），那么循环等待的条件就不会成立。
- 举例： 假设有两个事务T1和T2，都需要更新
```
accounts
```
  登录后复制
  表中的两条记录
```
id=1
```
  登录后复制
  和
```
id=2
```
  登录后复制
  。
  - 错误做法（可能导致死锁）：
    - T1:
      UPDATE accounts SET balance = ... WHERE id = 1;
      登录后复制
    - T2:
      UPDATE accounts SET balance = ... WHERE id = 2;
      登录后复制
    - T1:
      UPDATE accounts SET balance = ... WHERE id = 2;
      登录后复制
      (等待T2释放id=2的锁)
    - T2:
      UPDATE accounts SET balance = ... WHERE id = 1;
      登录后复制
      (等待T1释放id=1的锁)
  - 正确做法（避免死锁）： 总是先锁定id较小的记录。
    - T1:
      UPDATE accounts SET balance = ... WHERE id = 1;
      登录后复制
    - T1:
      UPDATE accounts SET balance = ... WHERE id = 2;
      登录后复制
    - T2:
      UPDATE accounts SET balance = ... WHERE id = 1;
      登录后复制
      (T2会等待T1释放id=1的锁)
    - T2:
      UPDATE accounts SET balance = ... WHERE id = 2;
      登录后复制
  - 或者，更直接地一次性锁定所有需要的行：
    - SELECT * FROM accounts WHERE id IN (1, 2) FOR UPDATE;
      登录后复制
    - UPDATE accounts SET balance = ... WHERE id = 1;
      登录后复制
    - UPDATE accounts SET balance = ... WHERE id = 2;
      登录后复制
缩短事务持续时间： 事务持有锁的时间越短，发生冲突和死锁的可能性就越小。尽量让事务只包含必要的数据库操作，并尽快提交或回滚。
使用索引优化查询： 良好的索引设计能让MySQL更快地定位到需要锁定的行，减少扫描范围，从而减少不必要的锁。如果查询没有使用索引，InnoDB可能会执行全表扫描并锁定更多的行，增加死锁的风险。
使用
```
SELECT ... FOR UPDATE
```
登录后复制
显式锁定： 在需要修改数据之前，通过
```
SELECT ... FOR UPDATE
```
登录后复制
语句提前获取排他锁，可以明确地建立锁定顺序，避免在后续的
```
UPDATE
```
登录后复制
操作中因为隐式锁导致死锁。这尤其适用于“先查询后更新”的业务逻辑。
减少并发冲突： 从业务逻辑层面思考，是否可以调整操作顺序或设计，减少对相同资源的并发访问。例如，将高并发操作拆分为更小的批次，或者引入队列机制。
设置合理的
```
innodb_lock_wait_timeout
```
登录后复制
：这个参数定义了事务等待锁的超时时间。如果一个事务等待锁的时间超过这个值，InnoDB会认为它可能陷入死锁，并回滚该事务。虽然这不是避免死锁的策略，但它是一种有效的恢复机制，可以防止事务无限期地等待下去。

理解MySQL锁机制：为什么并发控制如此重要？

在我看来，理解MySQL的锁机制，特别是InnoDB的实现，是每个数据库开发者和管理员的“必修课”。它不仅仅是技术细节，更是我们构建高并发、高可用系统的基石。说实话，如果没有一套行之有效的并发控制机制，我们几乎无法想象在多用户同时操作的场景下，如何保证数据的正确性。

并发控制的核心目的，在于在多个事务同时访问和修改数据时，依然能保证数据的完整性、一致性、隔离性和持久性（ACID特性）。想象一下，如果没有锁，两个用户同时尝试从同一个银行账户中取钱，或者同时更新一个库存数量，结果会是灾难性的：一个用户的操作可能覆盖另一个，或者账户余额变成负数，库存数据变得混乱。这在数据库领域，我们称之为“脏读”、“不可重复读”、“幻读”和“丢失更新”等问题。

锁，就是解决这些问题的“守护者”。它通过限制对共享资源的访问，来确保事务的隔离性。例如，当一个事务正在修改一行数据时，排他锁会阻止其他事务读取或修改这行数据，直到当前事务提交或回滚。这样就避免了“脏读”和“丢失更新”。而像间隙锁、Next-Key锁这些看似复杂的机制，实际上是为了在更高的隔离级别（如Repeatable Read）下，进一步防止“幻读”——即一个事务在两次查询之间，发现有新的行被其他事务插入了。

有道小P

有道小P，新一代AI全科学习助手，在学习中遇到任何问题都可以问我。

查看详情

当然，并发控制并非没有代价。锁的引入，必然会带来资源的争用，降低系统的并发度。如何在这两者之间找到一个平衡点，既保证数据正确性，又尽可能提升系统性能，是我们需要不断权衡和优化的方向。理解不同锁的粒度（行级、表级）以及它们在不同隔离级别下的行为，能帮助我们更精准地设计SQL语句和事务，从而最大限度地发挥数据库的性能潜力。

MySQL死锁的常见场景与识别方法

死锁这东西，就像是数据库里时不时冒出来的小麻烦，虽然InnoDB会自动处理，但它带来的事务回滚和重试成本，对用户体验和系统资源都是一种损耗。所以，了解它为什么发生，以及如何快速定位它，非常重要。

常见的死锁场景：

经典的“交叉等待”： 这是最典型的死锁模式。事务A锁定了资源R1，然后尝试锁定R2。同时，事务B锁定了资源R2，然后尝试锁定R1。结果就是A等待B释放R2，B等待A释放R1，形成一个循环等待。
- 例子： 两个事务同时更新两行数据，但更新的顺序相反。
  - T1:
```
UPDATE products SET price = 100 WHERE id = 1;
```
    登录后复制
    (获得id=1的X锁)
  - T2:
```
UPDATE products SET price = 200 WHERE id = 2;
```
    登录后复制
    (获得id=2的X锁)
  - T1:
```
UPDATE products SET price = 101 WHERE id = 2;
```
    登录后复制
    (尝试获取id=2的X锁，等待T2)
  - T2:
```
UPDATE products SET price = 201 WHERE id = 1;
```
    登录后复制
    (尝试获取id=1的X锁，等待T1)
  - 此时，死锁发生。
索引与间隙锁导致的死锁： 很多人以为死锁只发生在行数据上，但实际上，InnoDB的锁是基于索引的。间隙锁和Next-Key锁的存在，使得在插入或范围查询时也可能发生死锁。
- 例子： 假设有一个
```
orders
```
  登录后复制
  表，
```
order_id
```
  登录后复制
  是主键。
  - T1:
```
INSERT INTO orders (order_id, customer_id) VALUES (10, 101);
```
    登录后复制
    (在某个间隙获取插入意向锁)
  - T2:
```
INSERT INTO orders (order_id, customer_id) VALUES (20, 102);
```
    登录后复制
    (在另一个间隙获取插入意向锁)
  - 如果T1和T2的插入位置恰好导致它们需要对方已经持有的间隙锁（例如，它们都在尝试锁定同一个间隙的不同部分，或者一个事务在锁定一个间隙，另一个事务尝试在那个间隙内插入），就可能发生死锁。这通常发生在没有显式索引的列上进行范围查询或插入时，或者在二级索引上。
外键约束导致的死锁： 当表之间存在外键关系时，更新或删除父表记录可能会触发子表的级联操作，或者需要锁定子表记录以维护参照完整性。如果多个事务同时操作父子表，且操作顺序不当，也可能导致死锁。

识别死锁的方法：

当应用程序报告死锁错误时，我们需要知道如何查看MySQL的日志来定位问题。

```
SHOW ENGINE INNODB STATUS;
```
登录后复制
- 这是诊断InnoDB死锁最主要的工具。执行这个命令后，在输出结果中找到
```
LATEST DETECTED DEADLOCK
```
  登录后复制
  部分。这里会详细记录最近一次死锁的发生时间、涉及的事务ID、它们正在等待什么锁、持有什么锁，以及导致死锁的SQL语句。这部分信息是分析死锁的“金矿”。
- 通常，它会显示：
  - ```
  *** (1) TRANSACTION:
```
  登录后复制
  某个事务的信息。
- ```
*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
```
    登录后复制
    它正在等待的锁。
  - ```
  *** (2) TRANSACTION:
```
  登录后复制
  另一个事务的信息。
- ```
*** (2) HOLDS THIS LOCK(S):
```
    登录后复制
    它持有的锁。
  - 以及最终被回滚的事务。
MySQL错误日志：
- 死锁信息通常也会被写入MySQL的错误日志（
```
error.log
```
  登录后复制
  ）中。在生产环境中，定期检查错误日志是发现潜在问题的良好习惯。
```
information_schema
```
登录后复制
数据库：
- 虽然不如
```
SHOW ENGINE INNODB STATUS
```
  登录后复制
  直接，但
```
information_schema.INNODB_LOCKS
```
  登录后复制
  和
```
information_schema.INNODB_LOCK_WAITS
```
  登录后复制
  表可以提供当前正在进行的锁和锁等待信息。这对于实时监控锁争用情况很有用，但它们不记录历史死锁。
```
performance_schema
```
登录后复制
数据库：
- 在MySQL 5.7及更高版本中，
```
performance_schema
```
  登录后复制
  提供了更丰富的锁相关事件信息，例如
```
data_locks
```
  登录后复制
  和
```
data_lock_waits
```
  登录后复制
  。你可以通过查询这些表来获取更详细的锁活动和等待链，这对于复杂的性能分析非常有用。

优化策略：如何从根本上减少MySQL死锁的发生？

减少死锁的发生，本质上就是减少资源争用和打破循环等待条件。这需要我们在SQL编写、事务设计乃至应用架构层面进行深思熟虑。

严格执行一致的锁定顺序：

这真的要强调再强调。如果你的业务逻辑需要更新多条记录或多个表，请确保所有相关的事务都以相同的、预定义的顺序去获取这些资源的锁。例如，总是按照主键ID的升序或降序来更新行，或者总是先更新父表再更新子表。这听起来简单，但在复杂的业务场景中，如果没有明确的规范，很容易被忽略。

示例：

-- 假设我们需要更新id为5和10的两条记录
-- 总是先更新id小的，再更新id大的
START TRANSACTION;
SELECT * FROM your_table WHERE id = 5 FOR UPDATE; -- 锁定id=5
SELECT * FROM your_table WHERE id = 10 FOR UPDATE; -- 锁定id=10
UPDATE your_table SET column1 = 'new_value' WHERE id = 5;
UPDATE your_table SET column1 = 'another_value' WHERE id = 10;
COMMIT;

登录后复制

或者，更简洁地一次性锁定：

START TRANSACTION;
SELECT * FROM your_table WHERE id IN (5, 10) ORDER BY id FOR UPDATE; -- 一次性锁定，并确保按顺序
UPDATE your_table SET column1 = 'new_value' WHERE id = 5;
UPDATE your_table SET column1 = 'another_value' WHERE id = 10;
COMMIT;

登录后复制

保持事务短小精悍：
- 事务的生命周期越长，它持有锁的时间就越久，与其他事务发生冲突的可能性就越大。尽可能地将大型操作拆分成多个小事务，或者在事务中只包含必要的数据库操作，减少不必要的逻辑处理。一旦数据库操作完成，立即提交或回滚事务，释放锁资源。
优化索引设计和SQL查询：
- 一个好的索引能够让InnoDB快速定位到需要锁定的行，避免全表扫描或大范围的索引扫描，从而减少锁定的粒度和数量。例如，
```
WHERE
```
  登录后复制
  子句中的条件列应该有合适的索引。如果查询无法使用索引，InnoDB可能会锁定更多的行，甚至是整个表，这无疑增加了死锁的风险。
- 检查你的
```
EXPLAIN
```
  登录后复制
  输出，确保查询正在使用预期的索引。
善用
```
SELECT ... FOR UPDATE
```
登录后复制
：
- 在“先查询后更新”的业务模式中，如果不对查询结果进行显式锁定，那么在查询和更新之间的时间窗内，其他事务可能会修改这些数据，导致更新冲突甚至死锁。
```
FOR UPDATE
```
  登录后复制
  语句可以提前获取排他锁，明确地声明你的意图，有效地避免了后续更新时的不确定性。
考虑应用层面的并发控制：
- 在某些极端高并发的场景下，或者当数据库层面的锁粒度不够灵活时