发布于 由admin

MySQL高阶讲座之：`MySQL`的`Deadlock`：其`LIFO`死锁检测算法与`trx_sys`链表。

各位观众老爷们，早上好！今天咱们来聊聊MySQL里让人头疼，但又不得不面对的——死锁（Deadlock）。别怕，今天咱们用大白话，加上一些“骚操作”的代码，把这个“拦路虎”给安排明白了。

开场白：死锁是个啥玩意儿？

想象一下，两个吃货同时抢最后一块红烧肉，一个拿着筷子夹着不放，另一个拿着勺子挖着不松手，谁也不让谁，结果就是红烧肉在那里纹丝不动，俩人都吃不上。这就是死锁的“吃货版”解释。

在MySQL里，死锁就是两个或多个事务，互相持有对方需要的资源，都在等待对方释放资源，导致谁也无法继续执行下去，最终大家都卡住了。

正餐：LIFO死锁检测算法与trx_sys链表

MySQL为了解决死锁问题，搞了一套叫做“死锁检测”的机制。简单来说，就是MySQL会定期检查有没有事务陷入了互相等待的僵局，如果有，就“枪毙”其中一个事务，让其他事务得以继续执行。

死锁检测算法的核心，就是如何高效地找到这些“互相等待”的事务。MySQL用的是一种叫做“LIFO（Last In, First Out）”的策略，结合一个叫做trx_sys的链表来实现。

  1. trx_sys链表：事务江湖的“花名册”

    trx_sys你可以把它想象成MySQL事务管理系统里的一个大花名册，上面记录了所有活跃的事务的信息，包括事务ID、事务状态、事务持有的锁等等。这个链表的存在，方便MySQL能够快速地找到所有需要参与死锁检测的事务。

    用代码模拟一下trx_sys链表的数据结构（简化版）：

    typedef struct trx_t {
   ulint       id;          /* 事务ID */
   ulint       state;       /* 事务状态 (例如：RUNNING, WAITING) */
   ulint       lock_wait_count; /* 事务等待锁的数量 */
   struct trx_t* next;      /* 指向下一个事务的指针 */
} trx_t;

trx_t* trx_sys_list = NULL; // 全局变量，指向trx_sys链表的头

    这段代码定义了一个trx_t结构体，代表一个事务。id是事务的唯一标识，state是事务的状态，lock_wait_count表示事务正在等待的锁的数量。next指针指向下一个事务，这样就形成了一个链表。trx_sys_list是一个全局变量，指向链表的头部。

  2. LIFO策略：后来的“倒霉蛋”

    LIFO，也就是“后进先出”，意味着MySQL在选择“牺牲品”的时候，倾向于选择最近才开始等待锁的事务。

    为啥要用LIFO呢？原因很简单：后来的事务通常持有锁的时间更短，回滚的代价也更小。牺牲它，可以更快地释放资源，让其他事务恢复执行，从而减少死锁带来的影响。

    举个例子：

    • 事务A：已经执行了10分钟，持有了很多重要的锁。
    • 事务B：刚开始执行1分钟，只持有了几个不太重要的锁。

    如果发生死锁，MySQL通常会选择回滚事务B，因为它回滚的代价更小，对系统的影响也更小。

  3. 死锁检测流程：一场“寻凶”之旅

    死锁检测的过程，就像一场“寻凶”之旅，MySQL会遍历trx_sys链表，逐个检查事务之间的依赖关系，看看是否存在循环等待的情况。

    • 第一步：找到“嫌疑人”

      MySQL会从trx_sys链表中选择一个事务作为起点，这个事务必须是处于WAITING状态，也就是正在等待锁的事务。

    • 第二步：顺藤摸瓜

      从这个事务开始，MySQL会根据它正在等待的锁，找到持有这个锁的事务。然后，再找到持有这个锁的事务正在等待的锁，如此循环往复，就像顺着藤蔓摸瓜一样。

    • 第三步：确认“凶手”

      如果在摸瓜的过程中，MySQL发现回到了起点事务，这就说明存在循环等待，也就是发生了死锁！

    • 第四步：锁定“目标”

      如果确认发生了死锁，MySQL会根据LIFO策略，选择一个“倒霉蛋”事务进行回滚。通常，是那个等待锁时间最长的事务。

    • 第五步：执行“枪决”

      MySQL会回滚选定的事务，释放它持有的所有锁，让其他事务得以继续执行。

    用代码模拟一下死锁检测的过程（简化版）：

    // 函数：检测死锁
void detect_deadlock() {
   trx_t* current_trx = trx_sys_list; // 从链表头开始遍历

   while (current_trx != NULL) {
       if (current_trx->state == WAITING && current_trx->lock_wait_count > 0) {
           if (is_deadlock(current_trx)) { // 检查是否死锁
               trx_t* victim = choose_victim_lifo(); // 选择牺牲品
               rollback_transaction(victim); // 回滚事务
               break; // 结束检测，回滚一个事务即可
           }
       }
       current_trx = current_trx->next; // 移动到下一个事务
   }
}

// 函数：检查是否死锁
bool is_deadlock(trx_t* start_trx) {
   trx_t* current_trx = start_trx;
   while (current_trx != NULL) {
       // 模拟获取持有锁的事务
       trx_t* holding_trx = get_holding_transaction(current_trx->waiting_for_lock);
       if (holding_trx == NULL) {
           return false; // 没有持有锁的事务，不可能死锁
       }
       if (holding_trx == start_trx) {
           return true; // 找到循环等待，确认死锁
       }
       current_trx = holding_trx;
   }
   return false; // 没有找到循环等待，没有死锁
}

// 函数：选择牺牲品（LIFO策略）
trx_t* choose_victim_lifo() {
   // 这里简化了，实际实现会更复杂，需要考虑等待时间等因素
   trx_t* victim = NULL;
   trx_t* current_trx = trx_sys_list;
   while(current_trx != NULL){
        if(current_trx->state == WAITING){
            victim = current_trx; // 简单选择第一个等待的事务
            break;
        }
        current_trx = current_trx->next;
   }

   return victim;
}

// 函数：回滚事务
void rollback_transaction(trx_t* trx) {
   // 这里简化了，实际实现会更复杂，需要释放锁等
   printf("Rolling back transaction %lun", trx->id);
   trx->state = ROLLED_BACK;
   // ... 其他回滚操作
}

    这段代码模拟了死锁检测的核心流程。detect_deadlock函数遍历trx_sys链表，找到处于WAITING状态的事务，然后调用is_deadlock函数检查是否存在循环等待。如果确认死锁，就调用choose_victim_lifo函数选择牺牲品，最后调用rollback_transaction函数回滚事务。

加餐：死锁的常见场景与预防

了解了死锁的原理和检测机制，接下来咱们聊聊死锁的常见场景和预防措施。

场景 描述 预防措施
交叉更新 两个事务同时更新同一张表的不同行，但更新顺序相反。例如，事务A先更新行1，再更新行2；事务B先更新行2，再更新行1。 尽量保持事务更新顺序一致。如果必须交叉更新，可以考虑使用悲观锁或乐观锁。
锁升级 事务开始时只持有行锁，随着事务的执行，锁的范围扩大到表锁。例如，事务A先更新行1，再更新行2，如果行锁升级为表锁，可能会与其他事务发生死锁。 尽量避免锁升级。可以通过调整innodb_lock_wait_timeout参数来限制锁等待时间，或者优化SQL语句，减少锁的竞争。
外部锁 事务不仅持有MySQL的锁，还持有外部资源锁（例如，文件锁、网络锁）。如果多个事务同时竞争这些外部资源锁，也可能发生死锁。 尽量减少事务对外部资源的依赖。如果必须使用外部资源锁，要注意锁的获取和释放顺序，避免与其他事务发生死锁。
长时间事务 长时间运行的事务持有锁的时间较长，容易与其他事务发生锁冲突，增加死锁的概率。 尽量避免长时间事务。可以将大事务拆分成多个小事务，或者使用异步处理方式。
不合理的索引 不合理的索引会导致MySQL扫描更多的行，增加锁的竞争，从而增加死锁的概率。 优化索引。确保SQL语句能够使用到合适的索引，减少扫描的行数。
多个连接使用同一账户执行不同事务 多个连接使用同一账户，如果这些连接执行的事务之间存在锁竞争，可能会导致死锁。 为每个连接使用不同的账户。这样可以避免多个连接之间的锁竞争。

甜点：查看死锁信息

MySQL提供了多种方式来查看死锁信息，帮助我们诊断和解决死锁问题。

  1. SHOW ENGINE INNODB STATUS

    这是最常用的方式，可以查看InnoDB存储引擎的详细状态信息，包括死锁检测的日志。

    SHOW ENGINE INNODB STATUS;

    在输出结果中，找到LATEST DETECTED DEADLOCK部分，可以查看最近一次死锁的详细信息，包括涉及的事务、SQL语句、锁信息等等。

  2. INFORMATION_SCHEMA.INNODB_TRX

    这个表包含了所有活跃的InnoDB事务的信息，可以用来查找长时间运行的事务，或者正在等待锁的事务。

    SELECT * FROM INFORMATION_SCHEMA.INNODB_TRX;

  3. INFORMATION_SCHEMA.INNODB_LOCKS

    这个表包含了所有InnoDB锁的信息，可以用来查找锁的持有者和等待者。

    SELECT * FROM INFORMATION_SCHEMA.INNODB_LOCKS;

  4. performance_schema

    MySQL 5.6及以上版本提供了performance_schema，可以用来监控数据库的性能，包括锁的等待时间、锁的竞争情况等等。

    SELECT * FROM performance_schema.events_waits_summary_global_by_event_name WHERE EVENT_NAME LIKE 'wait/lock/table/sql/%';

总结：与死锁斗智斗勇

死锁是MySQL里一个比较棘手的问题，但只要我们了解了它的原理、检测机制和常见场景，就可以有效地预防和解决死锁问题。记住，多观察、多分析、多优化，才能在与死锁的斗争中取得胜利！

今天的讲座就到这里，希望大家有所收获。下次再见！

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注