企业官网建设流程全解析

1. 从一条报错开始：为什么 MySQL 的事务没那么简单

做后端开发或者数据库运维的朋友，多半都遇到过这样的情况：一个跑了很久的存储过程突然报错，仔细排查发现是事务中间执行了 DDL，导致前面已经写入的数据被自动提交了；或者两个并发事务明明都只是 UPDATE 同一条记录，却莫名其妙死锁回滚；再或者测试环境一切正常，上了生产后因为设置了不同隔离级别，导致报表数据出现奇怪的重复行。

这些问题的根源，基本都指向同一个东西：MySQL 的事务机制。

事务这个概念，任何一本数据库教材都会讲 ACID，但教材不会告诉你的是：InnoDB 底层到底怎么实现这些特性的？哪些 SQL 会偷偷帮你提交事务？REPEATABLE READ 隔离级别下为什么还会有幻读的讨论？分布式事务的 XA 到底是怎么协调多个数据库的？这篇文章从 MySQL 事务的控制语句、隐式提交、隔离级别到分布式事务，一层层把 InnoDB 的事务内幕扒开来看，结合我实际运维和排查过程中踩过的坑，把能直接用的知识点和操作经验都写出来。

这篇文章适合刚接触 MySQL 的开发者，也适合被线上事务问题折磨过的 DBA 和架构师。看完之后你会清楚：一个事务从 BEGIN 到 COMMIT 中间究竟发生了什么，为什么某些操作绝对不能放进事务里，以及如何在多库环境下保证数据一致性。

2. 事务控制语句：BEGIN、COMMIT、ROLLBACK 背后藏着什么

2.1 三条必备语句和它们的变体

MySQL 的事务控制语句其实是高度口语化的，日常用得最多的就是三件套：BEGIN（或者 START TRANSACTION）、COMMIT 和 ROLLBACK。

BEGIN; UPDATE account SET balance = balance - 100 WHERE user_id = 1; UPDATE account SET balance = balance + 100 WHERE user_id = 2; COMMIT;

这三条语句看起来没什么稀奇，但有几个细节值得展开：

第一，BEGIN 和 START TRANSACTION 基本等价，但 START TRANSACTION 后面还能带修饰符，比如START TRANSACTION READ ONLY表示开启一个只读事务，START TRANSACTION WITH CONSISTENT SNAPSHOT可以在事务第一句话就建立一致性读视图，后续所有普通 SELECT 都基于这个快照，不会因为别的事务提交而感知到变化。这一点在我们做报表导出时非常有用。

第二，ROLLBACK 默认是回滚到事务开始位置，但如果在事务中间设置了 SAVEPOINT，就可以回滚到指定保存点，而不是全部回滚。这个特性对长事务中某一步失败后的局部恢复非常有帮助。

BEGIN; INSERT INTO orders (order_id, amount) VALUES (1001, 500); SAVEPOINT sp1; INSERT INTO order_items (order_id, item_id) VALUES (1001, 55); -- 模拟某一步出错 ROLLBACK TO SAVEPOINT sp1; COMMIT;

这段事务的效果是：order_items 的插入被回滚，但 orders 的插入保留下来。执行ROLLBACK TO SAVEPOINT sp1之后，保存点 sp1 仍然存在，后续还可以继续操作。如果想让保存点失效，用RELEASE SAVEPOINT sp1。我实际中见过有人用 SAVEPOINT 实现批量导入任务里的“跳过坏行”逻辑——每处理若干行设置一个保存点，出错时只回滚这小批数据，效率比整体回滚高得多。

第三，autocommit 这个默认设置对事务行为的影响比很多人想象的大。MySQL 默认开启 autocommit，意味着每条单独的语句都会自动提交。你可以通过SET autocommit = 0关闭，或者通过SET SESSION autocommit = 0只影响当前会话。注意：关闭 autocommit 后，如果没有显式 COMMIT，那么这些操作在会话断开时会怎么样？很关键的一点是：MySQL 不会在连接断开时自动提交，而是所有未提交修改都会回滚。这跟 Oracle 的行为一致，但很多从 SQL Server 过来的人会容易搞混。

2.2 InnoDB 到底怎么保证“原子性”和“持久性”

控制语句只是入口，真正让事务可靠的是底层两个日志：redo log 和 undo log。

redo log 负责持久性。事务每做一次数据修改，InnoDB 会先把变更记录写到内存中的 redo log buffer，然后按照一定的策略刷到磁盘上的 redo log file。这个策略是由参数innodb_flush_log_at_trx_commit决定的，取值 0、1、2。取 1 时，每次事务提交都强制刷磁盘，性能有所牺牲但最安全；取 2 时，只写到操作系统缓存，由系统决定什么时候落盘，虽然性能好，但如果机器断电，最近的事务提交可能丢失。生产环境默认是 1，很多大流量业务为了性能会改成 2，这就要在数据安全与性能之间做取舍。我的建议是：金融类、交易类业务必须保持 1，日志、点赞这类允许少量丢失的业务再考虑 2。

undo log 负责原子性和 MVCC。事务修改数据时，InnoDB 会为每行记录生成一个反向操作记录到 undo log，同时维护一个隐藏的回滚指针。如果事务需要回滚，顺着 undo log 的链把数据恢复到之前的状态；如果其他并发事务需要读取旧版本数据，也是顺着这个链找到对应版本。所以 undo log 不只在 ROLLBACK 时有用，也是多版本并发控制（MVCC）的核心数据结构。

这里有个非常容易忽略的点：ROLLBACK 其实并不一定能把所有操作都恢复。对于 DDL 语句，比如 ALTER TABLE 做了表结构修改，MySQL 不支持事务性 DDL，执行后无法通过 ROLLBACK 撤销修改。这也是为什么我们在第 3 节要专门讲隐式提交——很多误操作就是没搞清楚哪些语句不参与事务。

2.3 事务中一条 UPDATE 的执行路径

把控制语句和底层日志串起来，一条 UPDATE 在事务中的完整路径大致是：

1. 事务开启（BEGIN），InnoDB 给事务分配一个事务 ID。
2. UPDATE 命中的行上锁，阻止其他事务修改同一条记录。
3. 修改前先把旧值写入 undo log。
4. 修改数据页并写入 redo log buffer。
5. 事务执行成功，应用层调用 COMMIT。
6. InnoDB 将 redo log 刷盘（取决于刷盘策略）。
7. 释放行锁，事务结束。

理解了执行路径，你就知道为什么长事务会引发严重问题：因为持有锁的时间太长，阻塞了其他事务；undo log 也不能清理，回滚段持续膨胀；binlog 和 relay log 产生大量延迟数据。所以，事务尽量短小精悍，不要把网络请求、外部接口调用、复杂计算都塞在事务里面。

有一个非常典型的反例：某开发者在事务里调用第三方支付接口，等待对方回调后才 COMMIT。结果支付接口响应超时，事务挂了几十秒，期间所有针对同一行数据的请求全部排队，数据库连接池被耗尽，最终整个系统雪崩。这种做法等于把不可控的外部依赖转换成数据库锁等待，怎么优化 SQL 都没有用。事务里只做数据库内部操作，外部依赖一律在事务外处理。

3. 隐式提交的 SQL：最容易被忽视的“坑王”

3.1 哪些语句会触发隐式提交

MySQL 区分“显式提交”和“隐式提交”。显式提交是你明确执行 COMMIT；隐式提交则是你执行了一些特殊语句，MySQL 会在执行之前自动帮你提交当前事务，而且这个行为无法通过参数关闭。

根据官方文档和实际测试，触发隐式提交的语句大致有几类：

第一类是 DDL 定义语句。CREATE TABLE、ALTER TABLE、DROP TABLE、TRUNCATE TABLE、RENAME TABLE、CREATE INDEX、DROP INDEX、CREATE DATABASE、ALTER DATABASE等，都会在当前事务中先隐式提交，再执行具体操作。

第二类是 DCL 权限管理语句。GRANT、REVOKE、SET PASSWORD、CREATE USER、DROP USER、RENAME USER等同样会触发隐式提交。

第三类是表锁和事务管理语句。LOCK TABLES和UNLOCK TABLES本身就会提交当前事务。这一点很多人忽略：在一个未提交事务里执行 LOCK TABLES，前面积累的操作会自动 COMMIT。

第四类是管理类语句，比如ANALYZE TABLE、OPTIMIZE TABLE、REPAIR TABLE等维护操作。

第五类比较隐蔽，SET语句中的某些操作也会触发隐式提交。具体来说，SET autocommit = 1、SET AUTOCOMMIT = 1会把当前事务直接提交。注意这里的细节：如果你把autocommit从 0 改为 1，MySQL 会提交当前事务；但从 1 改为 0，不会提交任何东西。同样，SET TRANSACTION ISOLATION LEVEL这种修改隔离级别的语句，在事务执行过程中是不能使用的，MySQL 会直接报错“Cannot change the isolation level during a transaction”，所以你必须先提交当前事务再改隔离级别。

3.2 一个生动的踩坑案例

我见过一个真实的案例，某公司做了个会员积分的批量重算任务，逻辑是：

BEGIN; UPDATE member_points SET points = points + 100 WHERE member_id = 1; UPDATE member_points SET points = points + 100 WHERE member_id = 2; -- ... 中间处理很多成员 TRUNCATE TABLE temp_processing_table; COMMIT;

开发者的本意是：如果中间出错，所有积分调整全部回滚。但因为TRUNCATE TABLE触发了隐式提交，前面几十万条积分更新在 TRUNCATE 之前就被提交了。后来任务执行到一半程序崩溃，事务回滚，但前面一部分积分更新已经生效，导致数据对不上，最后只能从 binlog 逆向排查恢复。

这个案例给所有人的教训就是：事务里绝对不能混入任何隐式提交语句。如果你在设计阶段就有这种需求，要么把 DDL 类操作放到事务外，要么改用事务性替代方案。比如 TRUNCATE 可以用 DELETE FROM 代替（前提是数据量允许且性能可接受），CREATE INDEX 可以提前建好，权限变更单独处理。

3.3 如何检查和避免隐式提交

避免隐式提交最有效的方法是分层思维：

• 业务逻辑层：事务内只允许 SELECT、INSERT、UPDATE、DELETE，绝不执行 DDL、DCL、锁表操作。
• 表结构变更：一律通过独立的变更流程执行，不要在业务代码里动态建表、建索引。
• 定期巡检：通过慢查询日志或者 binlog 分析，发现有异常的大量 COMMIT 行为时，回溯这些 COMMIT 前的语句，看是不是有隐式提交语句混入。

还可以利用 MySQL 的performance_schema.events_statements_history表来查看一个事务内实际上执行了哪些语句，以及这些语句之间的提交行为。虽然不能直接看到“隐式提交”四个字，但通过语句类型和提交时间戳，基本能定位问题。

我再补充一个容易被坑的场景：如果你在存储过程中使用了CREATE TEMPORARY TABLE，建立临时表本身不会隐式提交，但某些版本和配置下，临时表的操作可能会受事务影响。更稳妥的做法是：临时表的创建放在事务外，事务内只做数据写入和读取。

4. 隔离级别：READ COMMITTED 与 REPEATABLE READ 的实战差异

4.1 四种隔离级别和它们解决的问题

SQL 标准定义了四种隔离级别，按隔离程度从低到高分别是：READ UNCOMMITTED、READ COMMITTED、REPEATABLE READ、SERIALIZABLE。

READ UNCOMMITTED 允许读到其他事务尚未提交的数据，也就是“脏读”。在实际业务里几乎不会使用，因为它的隔离性太弱，数据完全不可信。

READ COMMITTED 解决脏读问题，只允许读取已经提交的数据版本。但在一个事务内，两次相同的 SELECT 可能因为其他事务提交而产生不同的结果，这就是“不可重复读”。

REPEATABLE READ 是 MySQL InnoDB 的默认隔离级别，它保证在同一事务内，多次读取同一数据结果一致。同时，InnoDB 通过间隙锁（gap lock）和 next-key lock 配合 MVCC，还在很大程度上解决了“幻读”问题。

SERIALIZABLE 是最严格的级别，相当于所有事务串行化执行，通过加锁和阻塞避免任何并发冲突。它解决全部问题，但代价是并发性能极差，基本只能用于对一致性要求极高、并发量很小的场景。

我写一个表格把这四种级别、是否解决脏读/不可重复读/幻读以及典型场景列出来：

4.2 InnoDB 的 MVCC 和一致性读视图

REPEATABLE READ 之所以能在一个事务内保持一致的读取结果，靠的是 MVCC 的“一致性读视图”（consistent read view）。关于这个视图的机制，很多文档讲得云里雾里，我尽量用通俗的方式讲清楚。

在 REPEATABLE READ 下，InnoDB 为每个事务在第一次执行 SELECT 时创建一个快照视图。这个视图记录了三组数据：当前活跃事务 ID 列表（小于最小活跃事务 ID 的版本可见）、已提交事务 ID 列表（大于最大已分配事务 ID 的版本不可见）、以及自己这个事务的 ID。

每条记录在 undo log 中保存着历史版本和事务 ID。SELECT 时，InnoDB 沿着 undo log 回溯，找到第一个“对当前事务可见”的版本。在 REPEATABLE READ 下，这个视图在整个事务期间保持不变，所以多次读到的数据一致。在 READ COMMITTED 下，每次 SELECT 都会重建一个新的视图，所以其他事务提交后，再次读取就能看到新版本，这就是不可重复读的由来。

这里面有一个很多人误解的细节：MVCC 解决的是“快照读”的一致性问题，但它不解决“当前读”的幻读问题。所谓快照读，就是普通的SELECT，不加 FOR UPDATE、不加 LOCK IN SHARE MODE；所谓当前读，是SELECT ... FOR UPDATE、SELECT ... LOCK IN SHARE MODE以及INSERT、UPDATE、DELETE，必须读取最新的已提交版本并且加锁。当前读场景下，InnoDB 依赖 next-key lock（记录锁 + 间隙锁）来防止幻读。如果你在 REPEATABLE READ 级别下执行了SELECT * FROM t WHERE id > 100 FOR UPDATE，InnoDB 会锁住所有符合条件记录的间隙，阻止其他事务在 id 大于 100 的范围内插入新记录。这也是 REPEATABLE READ 下大量并发插入会被阻塞的原因。

4.3 REPEATABLE READ 和 READ COMMITTED 的选型经验

MySQL 默认 REPEATABLE READ，这从历史兼容性上可以理解，但对很多业务来说，READ COMMITTED 确实更合适，因为它的锁范围更小，并发度更高，尤其在频繁插入和更新的场景下不容易触发间隙锁导致的死锁。

我记得某次排查一个“莫名其妙死锁”的问题，从SHOW ENGINE INNODB STATUS里看到的场景是：两个事务都在 REPEATABLE READ 级别下，对某结构化订单表执行范围查询加范围更新，因为间隙锁互相等待。分析后发现业务确实不需要 RR 级别的“可重复读”，只需要每一条 SELECT 读到最新已提交数据，于是把隔离级别改成 READ COMMITTED，死锁立刻消失，吞吐量明显提升。

在 READ COMMITTED 下，InnoDB 的间隙锁会被禁用，只保留记录锁，这能显著降低死锁概率。但相应地，如果一个事务内你需要多次读取同一条件的数据而保证结果不变，就不能依赖 READ COMMITTED，必须通过FOR UPDATE加锁或者改用 REPEATABLE READ。

我个人的经验法则是：

• 报表、数据导出、统计分析类任务，多用 REPEATABLE READ。因为一次报表查询可能分多个 SQL 拉取不同维度的数据，如果隔离级别太低，中途别的事务提交会导致报表前后口径不一致。
• 高频 OLTP 交易系统，优先考虑 READ COMMITTED。交易本身事务短小，对快照一致性要求低，反而更需要高并发和低锁冲突。
• SERIALIZABLE 尽量只在特定存储过程或者特殊业务逻辑中使用，不适合作为全局默认级别。

另外提醒一下，修改隔离级别有全局、会话、事务级三个作用域：SET GLOBAL TRANSACTION ISOLATION LEVEL READ COMMITTED影响新连接；SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED只影响当前会话；SET TRANSACTION ISOLATION LEVEL READ COMMITTED只影响下一个事务，执行后立刻生效，之后 BEGIN 开启的新事务按新级别运行。

4.4 隔离级别与锁的交互：FOR UPDATE 的坑

在 REPEATABLE READ 下，SELECT ... FOR UPDATE会加 next-key lock，而如果是通过唯一索引精确等值匹配某一行，记录存在时 InnoDB 会退化到仅加记录锁。但注意“记录存在”这个前提：如果等值匹配的记录不存在，InnoDB 会锁住这个值落在的间隙，从而阻塞其他事务插入该范围内的数据。

这个机制在实际中有个经典的坑：某企业在做“唯一手机号注册”功能时，并发两个注册请求同时检查手机号不存在，然后同时插入。因为 InnoDB 在 REPEATABLE READ 下会对不存在的唯一键值加间隙锁，处理不好就会出现死锁。这里的本质是：你把“检查再插入”这个过程拆成了多个步骤，等于自己制造了锁竞争窗口。正确的做法是直接把唯一约束建好，捕获插入时的唯一键冲突异常，而不是先 SELECT 再 INSERT。一旦陷入“检查+插入”模式，任何隔离级别下都难免有并发边界问题。

5. 分布式事务：XA 协议在 MySQL 里的实际用法与局限

5.1 为什么需要分布式事务

单体数据库时代，一条 UPDATE 可以保证多个表的数据一致性，因为所有修改都在一个事务里，受同一份 redo/undo log 保护。但当业务拆分到多个数据库，或者引入了消息中间件、缓存等其他存储，一个业务操作可能要更新两个数据库中的记录，或者先写数据库再发消息。这时候单机事务天然失效，需要分布式事务来协调多个参与者。

MySQL 的分布式事务能力，主要体现为对 XA 协议的支持。XA 是一个分布式事务规范，它定义了一个全局事务如何协调多个资源管理器（各个 MySQL 实例或其他数据库）完成原子提交。MySQL 在 InnoDB 层面实现了 XA，可以通过XA START、XA END、XA PREPARE、XA COMMIT、XA ROLLBACK这套命令来操作。

5.2 MySQL XA 事务的完整流程

XA 事务的核心思想是两阶段提交（2PC）：第一阶段，事务管理器向所有参与方发送准备提交请求，让每个数据库把事务所需资源都锁住并把 redo log 落盘；第二阶段，如果所有参与方都准备好，再发送最终提交指令。

下面是一个简单的 XA 事务示例，假设数据库 A 和数据库 B 分别存储账户和订单：

-- 数据库A：账户库 XA START 'xid-1001'; UPDATE account SET balance = balance - 200 WHERE account_id = 1; XA END 'xid-1001'; XA PREPARE 'xid-1001'; -- 数据库B：订单库 XA START 'xid-1001'; INSERT INTO orders (order_id, amount) VALUES (555, 200); XA END 'xid-1001'; XA PREPARE 'xid-1001'; -- 两个库都PREPARE成功后，两阶段提交 -- 数据库A XA COMMIT 'xid-1001'; -- 数据库B XA COMMIT 'xid-1001';

如果某个参与方 PREPARE 失败，就必须对已经 PREPARE 过的参与方执行 XA ROLLBACK，实现全体回滚。这个流程保证了要么两个库同时提交，要么同时回滚。

这里有一个细节：MySQL 的 XA PREPARE 之后，事务实际上已经进入了“悬置”状态。此时事务持有的行锁不会释放，redo log 已经落盘。如果之后协调者崩溃，PREPARE 过的事务既没有 COMMIT 也没有 ROLLBACK，MySQL 在恢复时会根据 XA RECOVER 的结果帮助 DBA 手动处理。

5.3 XA 事务的局限和替代方案

XA 给了我们一个看似完美的分布式事务方案，但实际落地时限制很多。

第一，XA 事务会显著提高锁竞争和时间开销。每个参与方都需要完成本地事务，并且 PREPARE 阶段需要同步等待所有参与方响应，性能不如普通事务。在跨机房、网络不稳的场景下，2PC 的可用性非常脆弱。

第二，MySQL XA 事务存在一个很经典的兼容性问题：XID 管理。XID 必须是全局唯一的字符串，而且使用相同的 XID 执行多次 XA START 会报错。分布式的协调器必须自己生成并维护 XID 状态，如果协调器本身崩溃，恢复就很麻烦。

第三，XA 只解决“原子提交”问题，不解决数据一致性中的所有问题。比如一个分布式事务里，数据库 A 提交成功、数据库 B 提交失败，无论怎么回滚，A 上已经产生的 binlog 会包含已提交事务，下游订阅 binlog 的系统可能已经处理了这部分数据，这就是“最终一致性”要额外处理的场景。

所以，在实际工程中，很多团队并没有大规模使用 MySQL 的 XA，而是采用其他方案：

• 事务消息：利用消息中间件的事务消息能力，先把本地事务和发消息放在同一个本地事务里，消息成功发送后再由消费者处理其他系统的事务，比如利用 RocketMQ 的事务消息。
• 本地消息表 + 定时任务补偿：在每个业务系统内建本地消息表，业务操作和写消息表在同一个本地事务完成，后台任务扫表投递消息，消息消费者执行后续操作，失败则重试。
• TCC（Try/Confirm/Cancel）：将分布式事务拆解成 Try 阶段预留资源、Confirm 阶段确认执行、Cancel 阶段回滚释放，适合需要强一致性的业务。
• Seata 这类分布式事务框架：基于全局事务协调器，对业务侵入较低，支持 AT（自动补偿）和 TCC 模式。

我个人建议是：能不用分布式事务就不用。很多业务通过接口幂等、状态机流转、事件溯源等手段，完全可以做到最终一致，规避 2PC 的性能和容灾问题。如果确实需要强一致性分布式事务，先认真评估数据量、并发量、跨库数量和网络条件，再决定是否引入 XA 或 TCC。

5.4 与分布式事务相关的常见误区

我见过不少同学把“主从复制”和“分布式事务”混为一谈。实际上，MySQL 主从复制本身并不是分布式事务，它只是 binlog 在时间轴上的异步或半同步回放。从库上产生的不一致，并不是事务原子性的问题，而是复制策略和网络延迟的问题。

另一个误区是把连接上的autocommit状态与 XA 混在一起。如果我开着autocommit = 0去执行 XA 事务，非 XA 的普通事务状态可能和 XA 事务状态互相干扰。具体来说，如果全局事务开始前有一个未提交的本地事务，执行 XA START 时 MySQL 会先隐式提交本地事务。这个默认行为很容易被忽视，需要在实际编码时注意。

6. 事务排查实战：从理论到应用的避坑指南

6.1 用 SHOW ENGINE INNODB STATUS 抓死锁和锁等待

我排查事务类问题最常用的命令之一就是SHOW ENGINE INNODB STATUS，它会输出当前 InnoDB 引擎的状态信息，包含最近一次检测到的死锁场景。如果只是锁等待而不是死锁，这个命令的输出就不一定包含有效信息，需要配合information_schema.innodb_trx、information_schema.innodb_locks（或performance_schema.data_locks）来查看当前持有锁和等待锁的会话。

一个典型的锁等待排查过程是这样的：

SELECT * FROM information_schema.innodb_trx\G SELECT * FROM performance_schema.data_locks\G SELECT * FROM performance_schema.data_lock_waits\G

先看innodb_trx表里哪些事务处于 RUNNING 状态，运行了多久，持有多少行锁；再看data_locks表里锁的类型和锁定的对象；最后看data_lock_waits表确认谁在等待谁的锁。

这里有个很实用的“近实时”分析方法：如果一个事务长时间没有 COMMIT，它持有的锁会一直阻塞其他事务。排查时可以先按 trx_started 排序，找出运行时间最长的那个事务，看它执行了什么语句，是否产生了长事务。通常这种长事务来自：业务代码漏写 COMMIT、外部调用超时导致事务挂起、或者应用崩溃后连接未释放。

6.2 事务回滚和提交失败后的数据修复

事务回滚不是所有情况下都能完美恢复数据。尤其是遇到 DDL 导致隐式提交后，前面的事务数据已经落盘，此时无法通过 ROLLBACK 恢复，只能靠备份或 binlog。稍微总结一下遇到这种问题的应对手段：

如果业务刚上线，发现数据有问题，第一时间检查是否开启了 binlog。只要 binlog 存在且记录格式是 ROW 模式，可以通过mysqlbinlog解析出具体时间段的 SQL 操作，定位被隐式提交的事务操作。如果开启了 GTID，还可以用 GTID 精确过滤到某几个事务。但即使如此，恢复过程也是痛苦的，涉及解析、批量回放和数据校验。所以，真正的防线依然是：把事务边界设计清楚，把 DDL 和 DML 分开，把外部依赖在事务外处理。

6.3 隔离级别与死锁的关联分析

回到死锁问题本身。死锁的产生需要两个或多个事务以不同顺序请求同一组资源，而间隙锁会显著扩大“资源”的范围，增加死锁概率。我在 REPEATABLE READ 下遇到过的最典型死锁是：事务 A 先查后改表 X，事务 B 先查后改表 Y，然后 A 再改 Y，B 再改 X。如果按“一致的顺序”访问表，比如都先 X 后 Y，死锁就不会发生。这个经验对所有事务设计都适用：多个事务更新多张表时，尽量保持相同的访问顺序；单张表内，尽量保证相同的索引路径。

另一个实用技巧是在死锁发生后，让业务侧做自动重试。死锁本身不一定是架构问题，有时候就是并发高峰下的正常冲突。MySQL 检测到死锁后，会回滚其中一个事务，并向客户端返回Deadlock found when trying to get lock; try restarting transaction这个错误。应用层捕获这个错误后，做一次重试，很多死锁问题就不知不觉被消化了。但如果重试后死锁依然频繁，那就要考虑减少锁粒度、拆分事务、改变隔离级别了。

6.4 隔离级别选择与参数调整的几条建议

如果你问我，一个全新的业务系统，MySQL 隔离级别应该选什么？我大概率会建议先理解业务再做决定，但可以给几条经过大量实践验证的建议：

• 默认保留 REPEATABLE READ，不要随手把全局隔离级别改成 READ COMMITTED。除非你确实遇到锁竞争或死锁频繁，并且业务上不要求可重复读。
• 如果生产环境要在两种级别之间切换，一定要先在压测环境对比验证。某些框架对隔离级别有默认假设，切换后可能产生不可预期的行为。比如一些 ORM 在 REPEATABLE READ 下依赖快照读取，切换后数据变化会让缓存失效或产生更新丢失问题。
• 监控长事务是重中之重。通过performance_schema的events_transactions_current表可以查看每个事务的状态和持续时间，设置告警，超过阈值（比如 10 秒）就报警人工介入。
• 谨慎调整innodb_lock_wait_timeout。默认是 50 秒，如果业务对锁等待敏感，可以调小到 5~10 秒，让锁冲突的请求快速失败，避免拖垮整个应用。但调小之后，短暂的锁波动也可能导致业务失败率上升，需要结合重试机制一起设计。

6.5 关于双写和分布式事务的最后一句话

如果你已经在跨库双写，比如同时写 MySQL 和 Redis，一定要明白这根本不是事务问题，而是“分布式一致性问题”。MySQL 事务管不了 Redis，XA 也管不了 Redis（除非 Redis 实现了 XA 接口，但实际极少用）。这种情况下，正确做法是：先更新 MySQL，再通过事务消息或 binlog 订阅触发 Redis 更新；或者反过来，先写 Redis 作为预占，再更新 MySQL，再异步删除或更新 Redis。任何一步失败都要有补偿机制，靠“重试 + 幂等”来兜底。这是我处理过无数次双写问题后的最深刻体会：分布式世界没有银弹，最终一致性才是常态，保证数据最终不丢、能对账、能纠正，比追求一次提交的强一致更现实。

7. 最后分享一个排障技巧

如果让我只留一个排查事务问题的习惯，那就是：在任何事务边界不清晰的地方，先打印出当前的@@session.autocommit值和事务状态，再把事务内每一条语句前后的时间戳记录到日志中。有了这两个信息，九成以上的事务问题都能在日志阶段就定位到，而不需要等到线上出一个慢查询事故才去排查。

我自己就是这么操作的。早些年处理过一单“数据库锁等待导致系统瘫痪”的线上问题，最后定位到原因是某个开发框架在请求结束时主动执行了 COMMIT，而业务代码里又嵌套了 BEGIN，导致事务边界完全失控。从那以后，我在所有项目的数据库工具类里都强制要求：记录的日志必须包含事务开启、提交、回滚三个节点，任何异常的事务生命周期波动都能通过日志回溯。这个习惯帮我省掉了无数不眠之夜，各位也可以试试。