MySQL 5.7 中 InnoDB 只读事务性能提升的核心是去除冗余开销：不分配事务 ID、不写 undo log、不持锁结构；满足显式声明、全程无写、不访问临时表等条件时，直接走轻量路径，逻辑读近乎零额外成本。
MySQL 5.7 中 InnoDB 的只读事务性能提升，核心不是“加了什么新功能”，而是**去掉了冗余开销**——尤其是避免为只读事务分配事务 ID、写入 undo log 和持有锁结构。只要满足特定条件，InnoDB 会直接走轻量级路径，逻辑读几乎零额外成本。
只读事务如何绕过事务 ID 分配
普通事务启动时，InnoDB 必须调用 trx_start_if_not_started_xa() 分配事务 ID（trx->id），并初始化回滚段指针；而只读事务若满足以下全部条件，会跳过这一步：
- 显式声明：以
START TRANSACTION READ ONLY或BEGIN READ ONLY开头（SET TRANSACTION READ ONLY不生效） - 全程无写操作：不执行
INSERT、UPDATE、DELETE、REPLACE、SELECT ... FOR UPDATE、SELECT ... LOCK IN SHARE MODE - 不访问临时表或用户变量（
@var）
一旦跳过事务 ID 分配，就省掉了 trx_sys->mutex 竞争和全局事务 ID 计数器递增，高并发下效果明显。用 SHOW ENGINE INNODB STATUS 查 TRANSACTIONS 部分，这类事务不会出现在列表中。
为什么 undo log 和锁结构也被跳过
只读事务不修改数据，自然不需要生成 undo log 来支持回滚；也不需要行锁或间隙锁来保证隔离性（除非用了 FOR UPDATE 这类语句，那就不是只读了）。但关键点在于：
- InnoDB 在只读事务内执行
SELECT时，仍需构造一致性读视图（read view），但该视图复用的是最近一个活跃事务的trx_id快照，而非新建 - 不持有
trx->lock结构体，避免了锁链遍历、死锁检测等开销 - 不参与
purge_sys队列，不会拖慢后台清理线程
注意：SELECT 本身仍要加 dict_table_t::mutex 读取表元数据，但这是共享锁，冲突极小；如果表结构频繁变更（如大量 ALTER TABLE），这个 mutex 可能成为瓶颈。
容易被忽略的“伪只读”陷阱
很多看似只读的操作，实际触发了事务升级，导致性能回归普通事务水平：
-
SELECT NOW()、SELECT UUID()、SELECT SLEEP(1)：函数内部可能隐式开启事务（尤其在autocommit=0下） - 查询含触发器的视图：触发器里的语句哪怕只是
SELECT，也可能激活事务上下文 - 使用
SELECT ... INTO @var：赋值操作让事务无法被识别为只读 - 连接池自动执行
SET NAMES utf8mb4后再发SELECT：如果SET语句在事务内执行，整个事务不再只读
验证是否真走只读路径，最直接方式是压测时观察 Innodb_rows_read 增速 vs Innodb_trx_rseg_history_len 是否几乎不变 —— 后者长期 > 0 就说明有 undo 积压，事务没真正轻量化。
真正决定只读事务性能的，从来不是语法有多“干净”，而是它能否彻底脱离事务管理器的调度链条。哪怕少一次 mutex 竞争、少一次内存分配，在每秒数万次的简单查询里，就是实打实的吞吐差距。
