只读事务在InnoDB中真正“轻量”的首要原因是不分配trx_id，省去全局锁和链表维护；其次跳过回滚段与undo日志，Server层提前拦截写操作，且MVCC快照构建更廉价。
只读事务不分配事务ID，省掉全局锁和链表维护
只读事务在 InnoDB 中真正“轻量”的第一个原因，是它通常根本不会被分配 trx_id。只有当事务第一次对用户临时表执行增删改时，才会触发分配；纯查询（哪怕跨多张普通表）全程不碰事务 ID 分配逻辑。而读写事务只要执行第一条 DML，就会立即从内存全局变量取值、自增、并可能刷盘到系统表空间页号 5 的 Max Trx ID 字段——这个过程需要持有 lock_sys->mutex 全局大锁，会阻塞其他事务的锁操作。
同时，InnoDB 自 5.6 起把事务链表拆成两个：read_only_trx_list 和 rw_trx_list。只读事务只挂入前者，不参与全局读写事务可见性判断（如 trx_sys->max_trx_id 更新、trx_sys->rw_trx_list 遍历），避免了高并发下链表遍历和锁竞争开销。
只读事务跳过回滚段分配和 undo 日志写入
读写事务一旦修改数据，就必须分配回滚段（trx->rseg）、预留 undo slot、写入 undo log —— 这些动作涉及 buffer pool 页面分配、日志刷盘、以及后续可能的 purge 线程清理。而只读事务完全绕过这套机制：它不生成任何 undo 记录，也不需要回滚段上下文，自然也就没有 undo 页面争用、purge 压力或相关 latch 持有。
常见错误现象：SHOW ENGINE INNODB STATUS 中看到大量 undo log entries 或 history list length 持续增长，基本可判定是读写事务密集写入导致，与只读事务无关。
Server 层提前拦截写操作，不进引擎层
使用 START TRANSACTION READ ONLY 开启的事务，MySQL Server 层会在解析阶段就检查语句类型。一旦遇到 INSERT、UPDATE、DELETE、REPLACE 等 DML，直接返回错误 ER_CANT_EXECUTE_IN_READ_ONLY_TRANSACTION，根本不会调用 InnoDB 的执行接口。这省掉了整个引擎层的行锁申请、聚簇索引查找、缓冲池页面访问等开销。
注意：BEGIN 或 START TRANSACTION 默认开启的是读写事务，即使里面只写 SELECT，也仍具备写能力，只是没触发分配而已——它的“潜在写权限”本身就有元数据开销。
只读事务的 MVCC 快照更廉价
只读事务的 read_view 构建逻辑更简单：它不需要将自己加入 trx_sys->rw_trx_list，因此其 up_limit_id 和 low_limit_id 计算不依赖活跃读写事务列表的实时快照。尤其在长事务较多的实例中，读写事务构建 read_view 时需遍历整个 rw_trx_list 并加锁，而只读事务只需读取当前 max_trx_id 和已提交事务 ID 列表，耗时稳定且无锁冲突。
容易被忽略的一点：如果只读事务中执行了 SELECT ... FOR UPDATE 或 LOCK IN SHARE MODE，它就不再是“只读”语义，Server 层会拒绝，但更重要的是——InnoDB 会把它当作读写事务处理，立刻分配 trx_id 并启用完整流程。这种隐式升级是性能拐点，务必检查 SQL 是否意外带锁。
