先明确本讲的讨论范围

这一讲讨论 ACID 中的隔离性，以 InnoDB 为对象。事务能力由存储引擎提供，并不是所有引擎都支持事务，例如 MyISAM 就不支持。本讲关注的是普通 SELECT 这类一致性读能看到哪个版本的数据；UPDATE、加锁读等“当前读”遵循另一套规则，要到行锁和 MVCC 细节的后续讲次再展开。

三种并发现象，对应四个隔离级别

多个事务并发执行时，可能出现脏读、不可重复读和幻读。隔离级别就是在“看到多少别人的修改”与并发效率之间做取舍：隔离越严，通常等待与冲突越多。

• 读未提交：别人尚未提交的修改，我也可能读到，因此会出现脏读。
• 读提交：只能读到别人已经提交的修改；同一事务里两次读取同一行，结果可能不同。
• 可重复读：事务在一致性读中看到的数据保持一致，别人中途提交的修改不会改变我已经看到的结果。
• 串行化：通过加锁让冲突的读写排队执行，读与读之间可以并发，读写、写写冲突时后来者等待。

用同一条时间线比较四个级别

设表 T 只有一行，c = 1。事务 A 与 B 先各自读到 1；接着 B 把 c 改为 2 但暂不提交，此时 A 读一次（V1）；B 提交后 A 再读一次（V2）；A 自己提交后又读一次（V3）。

• 读未提交：V1 已能看到 B 未提交的 2，所以 V1、V2、V3 都是 2。
• 读提交：V1 看不到未提交修改，仍是 1；B 提交后 V2 变为 2；V3 也是 2。
• 可重复读：V1、V2 都是 1，因为 A 在事务内保持同一个视图；A 提交后的 V3 属于新的读取，才看到 2。
• 串行化：A 读过这一行，B 的修改会被锁挡住，直到 A 提交；因此 V1、V2 是 1，V3 是 2。

视图是什么时候建立的

这里的“视图”指 InnoDB 的一致性读视图（read view），不是 CREATE VIEW 创建的视图。它决定一致性读能看见哪些版本。

• 读提交：每条一致性读语句开始时建立新的视图，所以语句之间可以看到新提交的数据。
• 可重复读：整个事务复用同一个视图。更准确地说，BEGIN 本身并不立即建立视图，而是在第一次一致性读时建立；需要立刻建立时可用 START TRANSACTION WITH CONSISTENT SNAPSHOT。
• 读未提交：直接读取记录最新值，不依赖视图。
• 串行化：主要靠加锁避免冲突。InnoDB 在该级别下，事务中的普通 SELECT 会被当作加共享锁的读取。

查看与设置隔离级别，先核对版本

• 启动参数写作 transaction-isolation，例如设置为 READ-COMMITTED；也可以在全局或会话层面设置。
• 查询变量时，MySQL 5.7.20 起使用 transaction_isolation，更早版本使用 tx_isolation；8.0.3 已移除后者。遇到“变量不存在”，先确认版本。
• InnoDB 默认是可重复读。从默认读提交的数据库（例如 Oracle）迁移时，应当评估业务是否依赖读提交语义，而不是机械地照搬配置。
• InnoDB 在读提交级别下不能使用 STATEMENT 格式的 binlog，需要行格式（MIXED 会自动改用行事件）；调整隔离级别时，也要一起检查复制与 binlog 配置。

可重复读适合什么场景

典型场景是对账：用上月余额、当前余额和本月明细核对是否一致。如果核对过程中有新交易提交，读提交下前后几次查询可能落在不同时点，结果对不上。可重复读让整个核对事务读取同一个时点的数据，逻辑更容易成立。代价是这个事务不能拖得太久，原因见后文。

MVCC：同一行，可以同时存在多个版本

InnoDB 修改记录时，会同时生成用于回滚的 undo 信息。沿着这些信息，可以从最新值一步步推回更早的版本。假设一行依次从 1 改为 2、3、4：三个不同时刻建立的视图，分别可能看到 1、2、4。越早的视图，需要回溯的版本越多。这就是多版本并发控制（MVCC）的基本思路。

• 一致性读不需要给读取的行加锁；另一个事务此时把 4 改成 5，不会与这些只读视图互相阻塞。
• “能看到哪个版本”由视图决定，“旧版本从哪里来”由 undo 提供，两者配合才构成可重复读。
• 这里是概念模型；版本可见性的具体判断规则，要到后续讲次再拆开。

长事务为什么危险

旧版本何时可以清理？当系统中已经没有任何视图还可能需要它们时，后台 purge 才能清理。长事务持有很老的视图，它提交之前，相关的旧版本都得保留。

• undo 空间持续增长，版本链变长，读取旧版本的成本也随之升高。
• MySQL 5.5 及更早版本的 undo 存放在系统表空间 ibdata 中，即使事务结束、空间可复用，文件也不会自动变小。较新版本支持独立 undo 表空间与截断，具体能力需要按部署版本核对。
• 长事务还可能长时间持有锁，阻塞其他事务。锁的问题在后续讲次展开。

事务怎么开始，决定了它会持续多久

很多长事务不是有意为之，而是启动方式被误用。

• 显式事务：BEGIN 或 START TRANSACTION 开始，COMMIT 提交，ROLLBACK 回滚。
• SET autocommit = 0：关闭当前会话的自动提交，连一条 SELECT 也会开启事务，并一直持续到 COMMIT、ROLLBACK 或断开连接。
• 有些客户端框架连接后默认关闭自动提交；再配合连接池的长连接，就容易形成意外的长事务。
• 更稳妥的做法是保持 autocommit = 1，用显式语句开启事务。在意多一次交互时，可用 COMMIT WORK AND CHAIN：提交当前事务的同时立即开启下一个，事务边界仍然清楚。

如何找到正在运行的长事务

information_schema.innodb_trx 记录 InnoDB 当前活跃事务。可以按 trx_started 与当前时间的差值筛选，例如找出持续超过 60 秒的事务：SELECT * FROM information_schema.innodb_trx WHERE TIME_TO_SEC(TIMEDIFF(NOW(), trx_started)) > 60。阈值要结合业务确定；这里整理的是排查思路，没有在生产库执行。

复习：怎样防止长事务

• 应用侧：确认框架没有默认关闭 autocommit；事务只包住必须原子执行的数据库操作，不把远程调用、文件处理等慢操作放进事务。
• 应用侧：只读查询不需要显式事务时，不要用 BEGIN 包起来；可以为只读 SELECT 设置执行时长上限（例如会话级 max_execution_time），但要避免误伤备份等本就耗时的任务。
• 数据库侧：持续监控 innodb_trx 中的事务时长和 undo 积压，超过阈值时告警，由人判断是否终止。
• 数据库侧：结合版本规划 undo 表空间与截断策略，并在测试环境用慢 SQL、未提交会话等场景提前演练。

本讲留下的检查顺序

• 先确认当前隔离级别和 MySQL 版本，再解释“为什么看不见”。
• 区分一致性读与当前读：看不见新数据，不代表更新时也会基于旧值。
• 遇到 undo 增长、查询变慢或锁等待，先查有没有长期未提交的事务。

先记住两层，而不是一串组件名

MySQL 并不是一个直接读取文件的 SQL 黑盒。Server 层负责理解请求、规划执行与协调过程；存储引擎负责数据存取。换一种存储引擎，并不意味着连接、解析和优化这些通用流程也要重写。第一讲最值得留下的是这条职责边界。

一条查询的主路径

以 SELECT name FROM products WHERE id = 42 为例，可以先用下面这条简化路径建立认知。它描述的是模块分工，不是源码函数调用顺序，也不表示每条语句都要重新建立连接。

• 连接器：建立会话、完成身份认证，并管理连接状态。
• 分析与预处理：识别 SQL 结构，检查语法和表、列等对象引用。
• 优化器：在可行方案中选择访问路径，例如使用什么索引、如何安排关联顺序。
• 执行器：按计划推进查询，通过存储引擎接口访问数据。
• 存储引擎：完成具体的数据读取，执行过程最终把查询结果交给客户端。

连接复用，解决的是建立连接的成本

建立连接涉及网络交互、认证和会话初始化，所以连接不应在每条 SQL 后都销毁。长连接有利于复用，但长期持有的会话也可能积累资源。对应用而言，连接池除了复用连接，还需要管理连接寿命和失效状态。这是由本讲延伸出的工程检查项，并非已经做过的性能测试。

• Sleep 表示连接当前空闲，不等于 SQL 正在执行。
• 空闲超时和查询执行超时是不同问题；不要用同一个参数解释两种现象。
• 资料提及的 mysql_reset_connection 是客户端 API，不是一条可以直接提交的 SQL。
• 权限相关行为需要结合权限类型与版本判断，不把本讲的简化描述理解为所有授权变更都只在重连后生效。

查询缓存：需要标注版本的历史组件

资料中的查询缓存保存的是查询语句与结果的对应关系。表被更新后，相关缓存可能失效，因此写入频繁的业务很难持续获益。MySQL 8.0 已移除这项功能，学习现代版本时，不应把它画成查询必经的一站。这里说的是旧版 Query Cache，也不能据此推断数据库完全没有缓存。

优化器决定方案，执行器落实方案

SQL 描述想得到什么结果，执行计划决定怎么得到它。同一个关联查询，先过滤哪张表、使用哪条索引，可能影响中间结果规模。优化器负责选择方案，执行器负责调用引擎完成工作。不能只凭 SQL 写法就断言实际执行顺序，也不能把“有索引”直接等同于“访问成本低”。

把扫描与返回分开看

如果筛选列没有可用索引，执行过程可能需要读取并检查许多行，最后只返回很少的结果。反过来，走索引也不代表只访问最终返回的行。资料提醒：慢查询日志中的 rows_examined 与存储引擎内部实际扫描量不一定完全相同，分析性能时应先明确指标的统计口径。

两个容易误判的地方

• 列不存在：本讲将其归入分析阶段；更细地说，语法正确之后还需要对象解析和语义检查，不能把它简单称为关键字拼写错误。
• 权限校验：不能记成“只在执行器检查一次”。资料已说明优化前可能有权限预检查；缺少权限时，也可能先报告权限错误，而不是暴露表结构信息。

复习时，先回答这三个问题

• 为什么换了存储引擎，SQL 仍然需要解析与优化？因为这部分通用能力由 Server 层承担。
• 查询只返回一行，为什么仍然可能很慢？返回行数不代表扫描量，还要检查访问路径。
• 在 MySQL 8.0 中找不到 query_cache_type，该往哪里排查？先确认版本差异，不要直接当作安装问题。

下一步学习

查询路径明确后，再沿着更新语句理解日志与事务。本专栏按实际学习进度追加笔记；尚未整理的课程不会预先发布为空文章。

先明确本讲的讨论范围

这里讨论启用 binlog 的 MySQL 与 InnoDB，以及一条更新语句所在事务的提交过程。连接、分析和优化仍然存在；新增的关键问题是：内存中的修改如何变得可恢复，两套日志如何对同一事务形成一致的提交结论。文中的路径是便于理解的简化模型，不等同于所有版本的源码调用顺序。

WAL：推迟刷数据页，不是完全不写磁盘

例如 UPDATE counters SET value = value + 1 WHERE id = 7。数据页可能先被读入内存，再产生修改；没有必要让事务每次都等待对应数据页写回磁盘。WAL 要求相关日志先于脏数据页持久化。日志本身也需要 I/O，其收益来自顺序写、写入合并等机制，而不是“只写内存就能保证安全”。提交与刷脏页是不同事件，不能画上等号。

两份日志，各自回答不同的问题

• redo log：由 InnoDB 管理，描述与数据页修改有关的重做信息，用于崩溃恢复。它不是长期保留所有业务操作的历史账本。
• binlog：由 Server 层管理，记录语句事件或行变更事件，可用于复制和配合备份恢复。不能简单把它理解为一份 SQL 文本列表。
• redo 空间会被循环复用，但必须先满足恢复安全条件；binlog 以追加和切换文件的方式记录，也会受保留与清理策略影响，不会永久自动保存。

一次更新，沿着提交边界看

先假设记录存在，并且事务最终选择提交。如果是显式事务，多条语句可以属于同一次提交；不能把下面的日志协调理解为每条 UPDATE 都独立提交。

• 执行器通过引擎取得目标行，计算新值，再调用引擎完成修改。
• InnoDB 修改内存中的数据页并生成 redo，在提交协调中进入 prepare 状态。
• Server 层将该事务的 binlog 纳入提交过程，满足相应持久化要求。
• 引擎完成 commit，事务结束。脏页可以随后按刷盘策略写回数据文件。

为什么需要 prepare 和 commit

如果让两份日志各自独立提交，中间发生崩溃就可能产生分歧：引擎已经认可事务，binlog 却缺失；或者 binlog 已包含事务，引擎却没有可恢复的对应修改。前者会让基于日志重放的库少一次更新，后者会让它多一次更新。两阶段提交让 Server 层和引擎围绕同一个事务协调结果，而不是仅仅规定两个文件谁先写。这里是数据库内部协调，不是说一次普通 UPDATE 要由应用发起跨服务分布式事务。

崩溃发生在中间，如何理解结果

以下是课程模型下的两种关键情况。判断依据是崩溃后可恢复且完整的日志信息，不能把“调用过写入函数”直接当成“已经可靠落盘”。

• 只有 prepare，没有匹配的完整 binlog：不能把它当成已提交事务，恢复时应回滚。
• 已经 prepare，且存在匹配的完整 binlog，但 commit 尚未完成：恢复过程可以完成提交，使引擎状态与日志重放结果一致。
• 因此，看不到最终 commit 标记不等于一定回滚。是否已向客户端返回成功，与恢复时如何认定事务，也不是同一个问题。

恢复到某个时间点，需要完整的恢复链

恢复误操作前的数据，通常需要一个早于目标时点的有效全量备份，以及从备份对应位置到目标位置的连续 binlog。先在独立环境恢复备份，再重放到误操作之前，核对后决定如何取回业务数据。不能把误操作后的所有事件盲目重放到修复库：后续业务可能已经基于错误状态继续写入。这里整理的是恢复思路，没有在真实数据库执行恢复操作。

参数与版本，别记成绝对承诺

• 课程介绍 innodb_flush_log_at_trx_commit=1 与 sync_binlog=1，用于加强 redo 和 binlog 的提交持久性。实际效果仍依赖系统与存储正确兑现持久化语义，不等于可以防住磁盘损坏或所有灾难。
• redo 的文件数量和容量示例不是所有版本的默认值；配置方式与具体实现需要按部署版本核对。
• binlog 可采用语句、行或混合格式。行事件内容还受配置影响，不能断言所有情况下都完整记录每列的前后镜像。
• 日志协调也不意味着 redo 单独实现了全部 ACID 特性。回滚、隔离与并发控制还有其他机制参与。

复习：每天全备比每周全备好在哪里

在日志完整且目标时点相同的前提下，更近的全量备份通常意味着需要重放的日志更少，主要改善恢复耗时，也就是 RTO。它同时增加备份存储与执行成本。允许丢失多少数据（RPO）还取决于日志持久化、异地保存等策略，不能仅凭全备频率下结论。

本讲留下的检查顺序

• 先分清内存修改、日志持久化、事务提交、数据页刷盘四个动作。
• 再比较 redo 的崩溃恢复职责与 binlog 的归档、复制职责。
• 最后用崩溃时点推演两阶段提交，而不是只背 prepare → binlog → commit。

先对齐业务里的「同一件事」

WMS 的收货、质检、库存、调拨、拣货和出库不是相互独立的接口。它们围绕单据、数量与状态构成一条业务链路。整理这类问题时，起点是把业务对象、状态流转和数量口径放到一起：库存在哪里被占用，什么时候释放，异常回退时应该回到哪个状态。

把重复消息作为明确的处理场景

在 WMS 与 OMS、LES、SAP、QMS 协同的过程中，关注点包括消息重复、状态错位与补偿失败。工程实践中会组合使用业务幂等标识、数据库唯一约束与事务，明确一次业务操作的边界。幂等标识围绕业务事件设计，避免把不同的合法操作混为同一次处理。

让失败有去处，让补偿可追踪

消息处理还需要任务状态、有限重试补偿与失败隔离。排查时沿着业务标识核对任务和单据：请求是否到达、是否已经处理、是否可以再次执行、库存与单据状态是否相符。无法自动恢复的异常需要留下足够信息，便于后续定位与处理。

值得留下的检查清单

• 梳理占用、释放、回退与异常恢复的状态变化。
• 明确业务幂等标识和数据库唯一约束的作用范围。
• 检查 MQ 任务状态、重试次数与补偿结果。
• 联合库存数量和单据状态核对业务是否完成。

从页面和任务的真实需求出发

库存列表、批量任务和报表的查询目标并不相同。性能治理可以先回到业务：这次需要哪些字段、查询范围有多大、结果如何分页、关联数据是否真的用得上。把需求边界说清楚，再分析具体 SQL，会更容易找到值得调整的位置。

把一次请求里的查询放在一起看

除了单条 SQL 的耗时，还要检查调用链是否存在 N+1、循环查库或无界查询。列表中的逐行查询可能隐藏在服务方法里；批量任务也可能重复获取相同的数据。整理数据依赖后，用批量查询减少重复访问，并限制一次处理的数据范围。

联合索引与查询结构一起考虑

针对复杂查询，可以结合过滤条件、关联关系与排序方式检查联合索引，同时限定扫描范围、拆分无效关联。索引调整和 SQL 改写需要回到原来的业务场景验证，尤其留意结果集合、数量口径和边界数据是否一致。

一个便于复用的排查顺序

• 定位具体页面、接口或批量任务。
• 结合 SQL 与调用链寻找重复查询。
• 检查扫描范围、关联关系和联合索引。
• 比较调整前后的结果正确性和执行表现。

从一个具体业务任务开始

这个原型围绕 WMS 智能采购展开：读取库存预警，结合供应商与历史订单数据，生成比价和补货建议。它是对 Agent 在业务流程中如何分工的一次探索，当前定位为原型实践。

主 Agent 编排，子 Agent 分工

方案基于 DeepAgents，由主 Agent 负责任务编排，采购分析与采购订单两个子 Agent 分别承担对应职责。分析与订单操作分开后，可以更清楚地描述每一步的输入、输出与业务责任，也便于核对流程停在哪一个环节。

通过 MCP 连接业务数据

MCP Server 通过 HTTP 调用 WMS REST 接口，获取库存预警、供应商和历史订单数据。工具围绕明确的业务数据工作，分析结果与实际接口返回保持联系，避免把模型生成的内容当作真实库存或真实订单。

订单创建保留人工确认

比价与补货建议进入订单操作前，保留 HITL（Human in the Loop，人在环中）人工确认。原型里的关键边界是：分析可以辅助判断，订单创建需要经过人的确认。这也是继续探索 Agent 业务落地时值得保留的设计原则。

原型结构

• 主 Agent：任务编排与流程衔接。
• 采购分析 Agent：库存、供应商与历史订单分析。
• 采购订单 Agent：衔接订单操作。
• MCP Server：经 HTTP 调用 WMS REST 接口。
• 人工确认：订单创建前的确认环节。