MySQL中锁的种类有哪些？如何避免死锁？（死锁.种类.有哪些.MySQL...）

wufei123 发布于 2025-09-11 阅读（2）
MySQL通过共享锁和排他锁等机制保证数据一致性，避免死锁需确保事务以一致顺序访问资源并缩短事务周期。

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

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

解决方案

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

MySQL中锁的种类：

  1. 共享锁（Shared Locks, S锁）与排他锁（Exclusive Locks, X锁）

    • S锁（读锁）：允许事务读取一行数据。多个事务可以同时持有同一行数据的S锁，因为读取操作通常不会相互干扰。
    • X锁（写锁）：允许事务更新或删除一行数据。当一个事务持有一行数据的X锁时，其他事务不能再获取该行的S锁或X锁，确保数据修改的原子性和隔离性。

  2. 意向锁（Intention Locks, IS/IX锁）

    • 这是表级别的锁，用于指示事务即将对表中的某些行加S锁或X锁。
    • IS锁（Intention Shared Lock）：事务打算在表中的某些行上设置S锁。
    • IX锁（Intention Exclusive Lock）：事务打算在表中的某些行上设置X锁。
    • 意向锁的存在是为了提高效率，当一个事务想要对整张表加S锁或X锁时，它不需要检查每一行是否有行锁，只需检查表上是否有意向锁即可。

  3. 记录锁（Record Locks）

    • 这是最基本的行锁，锁定的是索引中的一条记录。如果表没有定义任何索引，InnoDB会创建一个隐藏的聚簇索引，并使用它来锁定记录。

  4. 间隙锁（Gap Locks）

    • 锁定的是索引记录之间的“间隙”，或者第一个索引记录之前的间隙，或者最后一个索引记录之后的间隙。它的主要目的是防止其他事务在这些间隙中插入新的记录，从而解决幻读问题（在Repeatable Read隔离级别下）。

  5. Next-Key Locks

    • 这是InnoDB在Repeatable Read隔离级别下默认的行锁类型。它结合了记录锁和间隙锁的特性，锁定索引记录本身以及它前面的间隙。例如，如果一个索引包含值10, 20, 30，Next-Key锁可能会锁定(10, 20]这个区间，包括20这条记录。

  6. 插入意向锁（Insert Intention Locks）

    • 在插入新记录之前，事务会在插入位置（一个间隙）设置一个插入意向锁。这个锁是特殊的间隙锁，多个事务可以在同一个间隙内持有插入意向锁，只要它们插入的记录不冲突。

  7. 自增锁（AUTO-INC Locks）

    • 这是一种特殊的表级锁，用于处理
      AUTO_INCREMENT
      列的并发插入。它确保每次插入都能获得唯一的、连续的自增值。

如何避免死锁：

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

  1. 保持一致的锁定顺序： 这是避免死锁最有效、最核心的策略。如果所有事务都以相同的顺序访问和锁定多个资源（例如，总是先锁定表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;

  2. 缩短事务持续时间： 事务持有锁的时间越短，发生冲突和死锁的可能性就越小。尽量让事务只包含必要的数据库操作，并尽快提交或回滚。

  3. 使用索引优化查询： 良好的索引设计能让MySQL更快地定位到需要锁定的行，减少扫描范围，从而减少不必要的锁。如果查询没有使用索引，InnoDB可能会执行全表扫描并锁定更多的行，增加死锁的风险。

  4. 使用

    SELECT ... FOR UPDATE
    显式锁定： 在需要修改数据之前，通过
    SELECT ... FOR UPDATE
    语句提前获取排他锁，可以明确地建立锁定顺序，避免在后续的
    UPDATE
    操作中因为隐式锁导致死锁。这尤其适用于“先查询后更新”的业务逻辑。

  5. 减少并发冲突： 从业务逻辑层面思考，是否可以调整操作顺序或设计，减少对相同资源的并发访问。例如，将高并发操作拆分为更小的批次，或者引入队列机制。

  6. 设置合理的

    innodb_lock_wait_timeout
    ： 这个参数定义了事务等待锁的超时时间。如果一个事务等待锁的时间超过这个值，InnoDB会认为它可能陷入死锁，并回滚该事务。虽然这不是避免死锁的策略，但它是一种有效的恢复机制，可以防止事务无限期地等待下去。
理解MySQL锁机制：为什么并发控制如此重要？

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

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

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

PIA PIA

全面的AI聚合平台，一站式访问所有顶级AI模型

PIA226 查看详情 PIA

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

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

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

常见的死锁场景：

  1. 经典的“交叉等待”： 这是最典型的死锁模式。事务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)
      • 此时，死锁发生。

  2. 索引与间隙锁导致的死锁： 很多人以为死锁只发生在行数据上，但实际上，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的插入位置恰好导致它们需要对方已经持有的间隙锁（例如，它们都在尝试锁定同一个间隙的不同部分，或者一个事务在锁定一个间隙，另一个事务尝试在那个间隙内插入），就可能发生死锁。这通常发生在没有显式索引的列上进行范围查询或插入时，或者在二级索引上。

  3. 外键约束导致的死锁： 当表之间存在外键关系时，更新或删除父表记录可能会触发子表的级联操作，或者需要锁定子表记录以维护参照完整性。如果多个事务同时操作父子表，且操作顺序不当，也可能导致死锁。

识别死锁的方法：

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

  1. 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):
        它持有的锁。
      • 以及最终被回滚的事务。

  2. MySQL错误日志：

    • 死锁信息通常也会被写入MySQL的错误日志（
      error.log
      ）中。在生产环境中，定期检查错误日志是发现潜在问题的良好习惯。

  3. information_schema
    数据库：
    • 虽然不如
      SHOW ENGINE INNODB STATUS
      直接，但
      information_schema.INNODB_LOCKS
      和
      information_schema.INNODB_LOCK_WAITS
      表可以提供当前正在进行的锁和锁等待信息。这对于实时监控锁争用情况很有用，但它们不记录历史死锁。

  4. performance_schema
    数据库：
    • 在MySQL 5.7及更高版本中，
      performance_schema
      提供了更丰富的锁相关事件信息，例如
      data_locks
      和
      data_lock_waits
      。你可以通过查询这些表来获取更详细的锁活动和等待链，这对于复杂的性能分析非常有用。
优化策略：如何从根本上减少MySQL死锁的发生？

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

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

    • 这真的要强调再强调。如果你的业务逻辑需要更新多条记录或多个表，请确保所有相关的事务都以相同的、预定义的顺序去获取这些资源的锁。例如，总是按照主键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;

  2. 保持事务短小精悍：

    • 事务的生命周期越长，它持有锁的时间就越久，与其他事务发生冲突的可能性就越大。尽可能地将大型操作拆分成多个小事务，或者在事务中只包含必要的数据库操作，减少不必要的逻辑处理。一旦数据库操作完成，立即提交或回滚事务，释放锁资源。

  3. 优化索引设计和SQL查询：

    • 一个好的索引能够让InnoDB快速定位到需要锁定的行，避免全表扫描或大范围的索引扫描，从而减少锁定的粒度和数量。例如，
      WHERE
      子句中的条件列应该有合适的索引。如果查询无法使用索引，InnoDB可能会锁定更多的行，甚至是整个表，这无疑增加了死锁的风险。
    • 检查你的
      EXPLAIN
      输出，确保查询正在使用预期的索引。

  4. 善用

    SELECT ... FOR UPDATE
    ：
    • 在“先查询后更新”的业务模式中，如果不对查询结果进行显式锁定，那么在查询和更新之间的时间窗内，其他事务可能会修改这些数据，导致更新冲突甚至死锁。
      FOR UPDATE
      语句可以提前获取排他锁，明确地声明你的意图，有效地避免了后续更新时的不确定性。

  5. 考虑应用层面的并发控制：

    • 在某些极端高并发的场景下，或者当数据库层面的锁粒度不够灵活时

以上就是MySQL中锁的种类有哪些？如何避免死锁？的详细内容，更多请关注知识资源分享宝库其它相关文章！

相关标签： mysql 工具 ai mysql错误 sql语句 并发访问 为什么 red 有锁 sql mysql 架构 for select Error auto 循环 并发 事件 this 数据库 大家都在看： MySQL内存使用过高（OOM）的诊断与优化配置 MySQL与NoSQL的融合：探索MySQL Document Store的应用 如何通过canal等工具实现MySQL到其他数据源的实时同步？ 使用Debezium进行MySQL变更数据捕获（CDC）实战 如何设计和优化MySQL中的大表分页查询方案

标签:  死锁 种类 有哪些 

相关阅读

发表评论:

◎欢迎参与讨论，请在这里发表您的看法、交流您的观点。

最近发表

标签列表