ReadView可见性判断严格按四步短路执行：先判是否为本事务修改，再判是否早于min_trx_id，接着判是否晚于等于max_trx_id，最后查m_ids列表确认是否活跃；顺序不可调换。
ReadView可见性判断的四步执行顺序不能跳过
InnoDB每次扫描一行时，都会用该行的 DB_TRX_ID 和当前事务的 ReadView 做四步短路判断，顺序固定、不可调换。跳过或重排会导致看到错误版本，比如漏掉自己刚插入的行，或误读未提交数据。
-
DB_TRX_ID == creator_trx_id→ 当前事务自己改的，直接返回可见，不查其他字段 DB_TRX_ID → 修改者在 ReadView 创建前已提交，可见-
DB_TRX_ID >= max_trx_id→ 修改者事务在 ReadView 创建后才启动，不可见 - 否则落在
[min_trx_id, max_trx_id)区间内：查DB_TRX_ID是否在m_ids中；在则未提交→不可见，不在则已提交→可见
注意：第四步必须查 m_ids 列表，不是简单比大小。很多调试中看到“明明事务已提交却读不到”，往往是因为 m_ids 里还残留着 ID，而 DB_TRX_ID 恰好落在区间内又没做成员检查。
RC和RR下ReadView生成时机导致行为差异极大
同一段 SQL 在不同隔离级别下结果可能完全不同，根本原因不是逻辑变了，而是 ReadView 重建不重建。
- READ COMMITTED：每次
SELECT都新建 ReadView → 同一事务内两次查询可能看到不同结果（其他事务中途提交） - REPEATABLE READ：仅第一次
SELECT生成 ReadView，后续复用 → “可重复读”由此而来，但幻读仍可能发生（因新插入行的DB_TRX_ID可能落在可见范围内） - READ UNCOMMITTED：不走 ReadView，直接读最新版本 → 可能读到
DB_TRX_ID对应未提交事务的数据
特别注意：SELECT ... FOR UPDATE、UPDATE、DELETE 是当前读，完全绕过 ReadView，直接读最新版并加锁——这解释了为什么在 RR 下执行 SELECT ... FOR UPDATE 后再普通 SELECT，会发现“刚刚还看不到的数据现在能看到了”。
长事务卡住 m_ids 会让undo log无法清理
ReadView 的 m_ids 是生成时刻所有活跃事务 ID 的快照。如果一个事务长时间不提交（比如开了事务但没 COMMIT 或 ROLLBACK），它就会持续出现在后续所有新 ReadView 的 m_ids 中。
- 后果1：旧版本数据始终“可能被需要”，InnoDB 不敢 purge 对应的 undo log，磁盘空间持续增长
- 后果2：
min_trx_id被钉住不前进，拖慢整个实例的 purge 线程进度 - 后果3：监控
information_schema.innodb_trx时，若发现trx_state = 'RUNNING'且trx_started超过 300 秒，基本可判定是 bug 或连接池配置异常，不是业务设计所需
这种问题不会立刻报错，但会缓慢恶化。线上必须定期扫描这类长事务，而不是等磁盘爆满或查询变慢才介入。
DB_TRX_ID 为 0 或极大值时的特殊处理
DB_TRX_ID 是 6 字节无符号整数，理论最大值约 281 万亿，但实际中两个边界值容易引发误判：
- 刚插入的行，若事务未提交，
DB_TRX_ID就是当前事务 ID；但如果通过INSERT ... SELECT或 bulk load 写入，某些场景下DB_TRX_ID可能为 0 —— 此时 InnoDB 会特殊处理，按“已提交”对待（因为 0 不可能是真实事务 ID） - 极高的
DB_TRX_ID（比如接近 2^48）通常表示事务 ID 环绕或系统异常，MySQL 会将其视为未来事务，按DB_TRX_ID >= max_trx_id规则判定为不可见
这些边界情况不会出现在常规 DML 流程中，但在排查备份恢复、主从同步或 XtraBackup 异常时，看到 DB_TRX_ID = 0 或超大值，要意识到它触发的是例外路径，不是标准四步判断。
