同一事务先后读取数据是否变化，与隔离级别和读取类型都有关系。不能用“加了事务”一句话解释。
本文使用MySQL 5.6、InnoDB 与独立测试数据库。数据库研究要同时观察表结构、数据分布和实际语句。本文讨论 InnoDB（事务存储引擎），不把其他存储引擎或后续版本特性当作相同行为。
1. 从现象推到机制
InnoDB 的一致性读取利用版本信息构造可见结果，锁定读取则面向需要锁住的当前记录。可重复读与读已提交创建读取视图的时机不同，普通 SELECT 与带锁 SELECT 也不应混为同一种行为。
图中的四个节点分别表示事务开始、版本读取、并发提交、再次查询。顺着实线检查输入如何变成输出，再沿虚线核对反馈条件。图示表达的是本文讨论的关系，不是实测曲线或现场截图。
2. 最小实现与输入条件
两个连接按固定顺序执行：A 开事务读取，B 更新并提交，A 再读取。之后再单独比较带锁读取，不把两组实验交叉。
1
2
3
4
5
-- 连接 A
START TRANSACTION;
SELECT value FROM demo_row WHERE id=1;
-- 连接 B 修改并提交后，A 再次普通读取
SELECT value FROM demo_row WHERE id=1;
先保存建表语句、索引与隔离级别，再准备固定演示数据。并发行为使用两个独立连接按顺序执行；执行计划、锁等待和最终数据需要结合，单看查询耗时不足以解释原因。
3. 用对照区分原因
下表列出需要主动改变的条件。预期行为来自机制分析，复现时还需记录运行环境和原始输出，不能将预期当作已经测得的结果。
| 改变的条件 | 需要验证的行为 |
|---|---|
| 可重复读内重复普通查询 | 可见结果受同一读取视图约束 |
| 切换为读已提交 | 后续语句可能看到新提交 |
| 使用锁定读取 | 行为应按当前读和锁规则分析 |
对照 1：可重复读内重复普通查询
可见结果受同一读取视图约束。观察时记录首次一致性读的时刻。把这个条件与基准情形分开，有助于判断变化来自哪一层；若得到相反结果，应先核对前提，再修改实现。
对照 2：切换为读已提交
后续语句可能看到新提交。观察时记录每次读取对应的提交点。把这个条件与基准情形分开，有助于判断变化来自哪一层；若得到相反结果，应先核对前提，再修改实现。
对照 3：使用锁定读取
行为应按当前读和锁规则分析。观察时记录实际锁等待与可见行。把这个条件与基准情形分开，有助于判断变化来自哪一层；若得到相反结果，应先核对前提，再修改实现。
4. 适用条件与取舍
快照一致性不等于不会发生业务竞争。基于旧快照决定库存扣减时，仍需要数据库条件更新或适当锁定。
一次正常运行只覆盖了这组输入。继续扩展前，应把上面的异常对照保留下来，尤其关注“使用锁定读取”这一分支。后续方案若改变了图中任意一处依赖，原来的判断就要重新验证，不能仅凭界面相似或返回值相同沿用结论。
