只读事务中纯select不分配trx_id且不使用undo段。innodb对显式read only事务优化：无dml/ddl/显式锁时，不生成事务id、不参与mvcc版本链、不持锁、不拖慢undo回收；但若涉及唯一约束检查或首次访问数据页，可能隐式升级为读写模式。
只读事务中的SELECT不分配事务ID，也不使用回滚段
MySQL（InnoDB）对显式声明的只读事务（START TRANSACTION READ ONLY）做了专门优化：只要事务内所有语句都是SELECT（不含SELECT ... FOR UPDATE或SELECT ... LOCK IN SHARE MODE），InnoDB 就不会为其分配事务ID（trx_id），也不会从回滚段（undo log）申请空间。
这意味着：
- 该事务不参与 MVCC 版本链构建，不生成新版本记录
- 不持有任何行锁或表锁（除非显式加锁）
- 不会被写事务的
purge线程清理影响，也不拖慢 undo log 回收 - 在
INFORMATION_SCHEMA.INNODB_TRX中可能查不到它（取决于是否已执行过语句）
但注意：SELECT 是否真“只读”，得看有没有隐式升级。比如：
- 如果 SELECT 查询涉及未提交的二级索引唯一约束检查（如插入前校验），可能触发内部写操作
- 如果 SELECT 被优化器重写为物化临时表并写入磁盘（
Using temporary; Using filesort），那只是磁盘临时表，和事务ID无关 - 一旦执行了任何 DML、DDL 或显式加锁的 SELECT，事务立即转为读写模式，立刻分配
trx_id并启用 undo
为什么READ ONLY事务能跳过trx_id分配
InnoDB 的事务ID本质是用于 MVCC 和锁管理的标识符。只读事务既不修改数据，也不需要生成一致性视图快照（它直接复用最近的已提交快照），所以无需独立 trx_id。它的“一致性读”靠的是当前全局 read view 的最小活跃事务ID（up_limit_id）来判断可见性，而非自身ID。
这种设计大幅降低高并发只读场景下的内存与日志开销——比如报表服务大量执行SELECT COUNT(*)，用READ ONLY可避免无谓的事务ID争用和 undo 段膨胀。
如何验证一个SELECT是否真的没分配trx_id
最直接的方式是查 INFORMATION_SCHEMA.INNODB_TRX 表，并对比执行前后：
- 开启只读事务：
START TRANSACTION READ ONLY; - 执行纯
SELECT：SELECT * FROM users LIMIT 1; - 立刻查表：
SELECT trx_id, trx_state, trx_is_read_only FROM INFORMATION_SCHEMA.INNODB_TRX WHERE trx_mysql_thread_id = CONNECTION_ID();
如果返回空，说明尚未分配 trx_id；如果返回一行且 trx_is_read_only = 1 但 trx_id 是非零值，则说明事务已因某些原因（比如首次访问聚簇索引）被隐式激活——这通常发生在第一次真正访问数据页时，而非语句解析阶段。
真正容易被忽略的是：即使你写了 READ ONLY，只要连接之前执行过写操作（哪怕已 COMMIT），InnoDB 可能仍会复用旧事务上下文；更稳妥的做法是用新连接，或在事务开头加 SET SESSION innodb_read_only = ON;（需 SUPER 权限）配合验证。
