Mysql · XB 现场笔记

InnoDB 死锁会回滚整个受害事务

Thu, 20 Apr 2028 00:00:00 +0000

当多个事务形成不兼容锁请求的等待环时，就发生 InnoDB 死锁。开启死锁检测后，引擎选择一个受害者，回滚它的整个事务，使其他参与者能够继续。应用收到错误 1213（SQLSTATE 40001）。若只重试报错的那条语句，就会漏掉同一事务中更早执行、但已经一起被回滚的工作。

坏掉的样子

不能给所有锁错误套用同一种回滚规则。默认关闭超时整笔回滚时，锁等待超时只撤销正在等待的那条语句，事务内此前执行的语句仍然待决。开启对应服务端选项后，超时才会改为回滚整个事务。死锁本来就会回滚整个受害事务，不能把默认超时的语句级行为误套在死锁上。

受害者选择也不保证某个固定会话永远输。应用必须检查真实错误，再以有界次数重试完整逻辑事务。不可逆的外部副作用如果没有单独去重契约，不应跟着数据库事务自动重放。提交回复途中连接断开，也不等于已经得到死锁回滚的确定结论；错误类型与已知事务结果需要分开判断。

快速验证

历史三会话测试保持原样；当前没有 MySQL 服务器，因此本次没有重跑。

在可丢弃的 MySQL 8.4 实例上打开甲、乙和观察者三个全新管理客户端，先确认三个会话均处于自动提交模式，关闭客户端自动重新连接，保持会话身份稳定。既有运行记录中的版本是 MySQL 8.4.11。观察者先创建尚未使用的实验模式，并核对死锁检测开启、超时采用默认语句级回滚：

CREATE DATABASE xbcatm_deadlock_lab;
USE xbcatm_deadlock_lab;
CREATE TABLE accounts (id INT PRIMARY KEY, balance INT NOT NULL) ENGINE=InnoDB;
INSERT INTO accounts VALUES (1,100),(2,100);
SELECT @@innodb_deadlock_detect,@@innodb_rollback_on_timeout;

两个设置应分别为一和零。甲开始一项给两个账户各增加十的操作，先锁住第一个账户：

USE xbcatm_deadlock_lab;
SET SESSION innodb_lock_wait_timeout=30;
SET @increment=10;
START TRANSACTION;
UPDATE accounts SET balance=balance+@increment WHERE id=1;

乙开始一项各增加一百的操作，先锁住第二个账户：

USE xbcatm_deadlock_lab;
SET SESSION innodb_lock_wait_timeout=30;
SET @increment=100;
START TRANSACTION;
UPDATE accounts SET balance=balance+@increment WHERE id=2;

甲再请求乙持有的那一行，此时语句会等待：

UPDATE accounts SET balance=balance+@increment WHERE id=2;

在甲的三十秒锁等待超时之前，乙执行反向请求：

UPDATE accounts SET balance=balance+@increment WHERE id=1;

其中一个会话收到死锁错误，把实际报错者认作受害者；另一个更新则会完成。下面的提交只在幸存会话中执行：

COMMIT;

观察者检查已经提交的状态：

SELECT id,balance FROM accounts ORDER BY id;

如果甲幸存，两行均为一百一十；如果乙幸存，两行均为二百。受害者更早的更新也已经消失。既有运行选择乙为受害者，最后看到两行一百一十。在受害者原来的会话中，用户变量仍然记录该操作的原始增量；现在按一致顺序取得两行，重试完整操作：

SELECT @increment;
START TRANSACTION;
UPDATE accounts SET balance=balance+@increment WHERE id=1;
UPDATE accounts SET balance=balance+@increment WHERE id=2;
COMMIT;

观察者核对组合结果：

SELECT id,balance FROM accounts ORDER BY id;

两行都必须变成二百一十。接下来对照锁等待超时。观察者先重置实验数据：

UPDATE accounts SET balance=100;

甲持有第一行的写锁：

START TRANSACTION;
UPDATE accounts SET balance=balance+1 WHERE id=1;

乙修改第二行，并设定较短等待时间：

SET SESSION innodb_lock_wait_timeout=1;
START TRANSACTION;
UPDATE accounts SET balance=balance+5 WHERE id=2;

仍在乙中请求甲持有的行：

UPDATE accounts SET balance=balance+5 WHERE id=1;

这次得到 1205（SQLSTATE HY000）锁等待超时错误，而不是死锁错误。乙检查自己事务里仍然待决的工作：

SELECT id,balance FROM accounts ORDER BY id;

乙读到一百和一百零五；观察者却仍然看到已提交的一百和一百：

SELECT id,balance FROM accounts ORDER BY id;

超时没有撤销乙此前增加的五。现在显式丢弃剩余事务，先在乙回滚：

ROLLBACK;

再在甲回滚：

ROLLBACK;

最后由观察者确认原始余额，并删除实验模式：

SELECT id,balance FROM accounts ORDER BY id;
DROP DATABASE xbcatm_deadlock_lab;

这项验证通过真实数据值区分回滚范围，而不只是相信错误消息里的文字。遇到不符合预期的结果就停止，先回滚仍然打开的实验事务，再进行清理。特别是超时之后不要直接提交残余操作，否则可能把业务操作的一部分留下，却误认为整笔工作已经失败并全部撤销。

减少等待环，但不假定它们消失

对共同业务资源采用一致的取得顺序，缩短事务，并使用合适索引，避免锁住超出操作需要的记录。范围操作与二级索引维护，还可能引入这个双主键行例子之外的锁交互。一致顺序能够减少已经识别的等待环，但不能证明所有可能的死锁都被移除，也不能替代错误发生之后的正确恢复逻辑。

可以通过引擎状态查看最近一次检测到的死锁；如果事件频率需要更长历史，应配置相应采集。把涉及的语句和锁顺序关联回完整应用事务，不要只盯着最后那条报错语句。重试应该在截止时间和尝试次数约束下重新执行完整工作，同时区分超时语义。最终还要核对业务结果，避免仅因为最后一次语句没有报错，就认为逻辑操作已经完整恢复。

来源

MySQL 8.4 InnoDB 错误处理，死锁整笔回滚与可配置的超时回滚范围，已核验 2026-09-12。
MySQL 8.4 死锁示例，复现等待环并检查实际受害者，已核验 2026-09-12。
MySQL 8.4 InnoDB 锁，并发操作涉及的记录锁与范围锁，已核验 2026-09-12。

InnoDB 覆盖索引包含查询所需的列

Fri, 03 Mar 2028 00:00:00 +0000

覆盖索引包含某条查询求值和返回结果所需的列。在 InnoDB 中，二级索引记录还会携带主键列，因此即使二级索引定义没有再次列出主键，某条查询也可能已经被覆盖。覆盖描述的是一条具体查询与某个索引之间的关系，不是给索引贴上标签之后，整张表的所有查询都自动获得同样行为。

坏掉的样子

增加返回列可能使覆盖失效。原本能提供标识和时间戳的索引，不一定包含应用后来开始读取的大载荷。优化器仍然可能沿用这个索引定位匹配记录，再访问聚簇记录取得缺失字段。因此，“用到了索引”和“由索引覆盖查询”是两件不同的事，不能从计划中出现索引名字就直接推导后者。

覆盖也不保证访问范围足够小。一个扫描大量条目的查询，可以完全被索引覆盖，仍然花费很多工作。列顺序、过滤条件、排序要求和行数估计都很重要。不要把 Using index 覆盖标记当作查询很快的证明，也不要把它与 Using index condition 索引条件下推标记混淆；后者描述部分条件在索引层求值，并不证明整个返回投影都在索引里。

InnoDB 的可见性检查还会限制通常所说的“只读索引”解释。二级记录不包含与聚簇记录相同的隐藏事务元数据。遇到删除标记条目，或被更新事务修改过的二级索引页时，可能仍需访问聚簇记录才能获得正确可见版本。因此，在并发多版本活动下，一个覆盖计划并不普遍保证聚簇访问次数永远为零。

快速验证

历史示例保持原样，当前没有 MySQL 8.4，因此本次没有重跑；计划结果仍属于既有运行记录。

准备一台新的 MySQL 8.4 实例，使用能够创建测试模式的客户端会话。既有运行记录中的版本是 MySQL 8.4.11。确认实验模式名尚未使用，遇到非预期 SQL 错误就停止，并保持同一个会话，以保留当前选中的数据库。下面建立一万行数据，其中一百笔已付款订单，并让载荷列明显比索引所需字段更宽：

CREATE DATABASE xbcatm_index_lab;
USE xbcatm_index_lab;
CREATE TABLE orders (
 id INT PRIMARY KEY,
 status VARCHAR(10) NOT NULL,
 created_at DATETIME NOT NULL,
 payload VARCHAR(1000) NOT NULL,
 INDEX by_status_created (status,created_at)
) ENGINE=InnoDB;
INSERT INTO orders
WITH digits(n) AS (
 SELECT 0 UNION ALL SELECT 1 UNION ALL SELECT 2 UNION ALL SELECT 3
 UNION ALL SELECT 4 UNION ALL SELECT 5 UNION ALL SELECT 6
 UNION ALL SELECT 7 UNION ALL SELECT 8 UNION ALL SELECT 9
)
SELECT number+1,IF(MOD(number+1,100)=0,'paid','open'),
 TIMESTAMP '2026-01-01 00:00:00' + INTERVAL (number+1) SECOND,
 REPEAT('x',640)
FROM (SELECT a.n+10*b.n+100*c.n+1000*d.n AS number
 FROM digits a CROSS JOIN digits b CROSS JOIN digits c CROSS JOIN digits d) AS numbered;
ANALYZE TABLE orders;
SELECT COUNT(*),SUM(status='paid') FROM orders;

最后的两个计数应为一万与一百。二级索引明确包含状态与创建时间，InnoDB 隐式提供主键标识。先检查并运行只需要这些值的查询：

EXPLAIN SELECT id,created_at FROM orders WHERE status='paid' ORDER BY created_at,id LIMIT 20;
EXPLAIN ANALYZE SELECT id,created_at FROM orders WHERE status='paid' ORDER BY created_at,id LIMIT 20;
SELECT id,created_at FROM orders WHERE status='paid' ORDER BY created_at,id LIMIT 20;

既有表格计划给出所建索引及覆盖访问标记，实际分析计划显示覆盖索引查找并返回二十行。结果标识依次为一百、二百，直到两千，按照时间戳与标识排序。这是在已经填充数据的表上核对过的实际结果，不是从一个空模式推测查询会采用什么访问路径。

接着，把载荷也加入返回列：

EXPLAIN SELECT id,created_at,payload FROM orders WHERE status='paid' ORDER BY created_at,id LIMIT 20;
EXPLAIN ANALYZE SELECT id,created_at,payload FROM orders WHERE status='paid' ORDER BY created_at,id LIMIT 20;

既有计划仍使用同一个索引，却不再具有覆盖标记；实际分析也变成没有覆盖限定的索引查找。这保持了过滤、排序和索引不变，只改变所需返回列，因而能够明确观察投影变化的影响。实际分析命令会真正执行查询，对真实的大查询使用它时，应把这次诊断本身的执行代价算进去。

最后删除本次实验自己创建的模式：

DROP DATABASE xbcatm_index_lab;

这个小型热缓存实验的时间不能当成吞吐量或延迟基准。调度、缓存和测量本身的开销，可能超过两次二十行查询之间的差别。这里验证的是访问形态与结果内容，而不是承诺物理输入输出减少某个固定比例，更不能据此保证生产请求的高分位延迟必然下降一半。

有意识地承担覆盖成本

给二级索引追加字段会占用存储与缓冲池容量，并在相关索引值变化时增加维护工作。较长的主键也会扩大二级索引条目。应覆盖重要而窄的查询，不要默认把大载荷复制到每个索引里。明确列出返回字段，也有助于后续应用变更在审阅时暴露新的数据访问要求，避免一个查询投影变化悄悄改变成本。

保留新增索引之前，应比较代表性的计划、检查行数、前台延迟以及写入代价。使用真实选择率和并发活动进行验证；安静夹具并没有测量可见性检查需要聚簇访问的频率，也没有测量副本维护这些索引的成本。索引应当通过它实际服务的工作负载证明价值，而不是仅因为一次解释输出里出现了期望的标签。

来源

MySQL 8.4 聚簇索引与二级索引，二级记录携带主键列的机制，已核验 2026-09-12。
MySQL 8.4 EXPLAIN 输出，索引使用与覆盖计划标记，已核验 2026-09-12。
MySQL 8.4 InnoDB 多版本机制，二级索引可见性检查需要聚簇访问的条件，已核验 2026-09-12。