只读事务不分配事务ID，除非显式升级为读写；InnoDB仅在执行写操作（如INSERT/UPDATE/DELETE/DDL）或声明READ WRITE时分配trx_id并生成undo log，纯SELECT不触发分配，可通过INFORMATION_SCHEMA.INNODB_TRX验证。
只读事务不分配事务ID，除非显式升级为读写
MySQL（InnoDB）对只读事务做了优化：只要事务中**没有执行任何修改数据的语句**（如 INSERT、UPDATE、DELETE、REPLACE、DDL），且未显式声明为读写（START TRANSACTION READ WRITE），InnoDB 就不会为其分配事务ID（trx_id）。这意味着它不会写入 undo log，也不会参与 MVCC 版本链构建。
常见误区是认为“开了事务就一定有 ID”——其实只读事务在多数场景下是“无状态”的轻量级会话。
- 判断依据是实际语句，不是
BEGIN或START TRANSACTION本身 -
SELECT+LOCK IN SHARE MODE或FOR UPDATE属于读写事务语义，会触发事务ID分配 - 即使事务里只有
SELECT，但后续执行了UPDATE，事务ID会在第一条修改语句执行时才分配（非事务开始时）
读写事务在第一个修改操作时立即分配事务ID
一旦事务执行了任意一条写操作（包括 UPDATE ... LIMIT 1 这种看似“小”的更新），InnoDB 就会在该语句执行前为其分配一个全局唯一的递增 trx_id，并创建对应的 undo log 段。这个 ID 是 MVCC 快照、Read View 构建和行锁归属的核心依据。
注意：事务ID分配时机与 autocommit 设置无关，也与是否显式 START TRANSACTION 无关——只要语句属于一个活跃事务上下文且带写语义，就会触发分配。
- 显式开启的事务：
START TRANSACTION; UPDATE t SET x=1 WHERE id=1;→UPDATE执行前分配 ID - 自动提交模式下的单条语句：
UPDATE t SET x=1 WHERE id=1;→ 同样分配 ID（它本身就是独立事务） - DDL 语句（如
ALTER TABLE）总是读写事务，必然分配 ID，且会隐式提交前后事务
如何验证事务是否获得ID
直接查 INFORMATION_SCHEMA.INNODB_TRX 表是最可靠方式。只读事务（未升级）不会出现在该视图中；而一旦执行写操作，它就会立刻出现，并携带 TRX_ID、TRX_STATE、TRX_STARTED 等字段。
示例：
SELECT TRX_ID, TRX_STATE, TRX_MYSQL_THREAD_ID, TRX_QUERY FROM INFORMATION_SCHEMA.INNODB_TRX WHERE TRX_MYSQL_THREAD_ID = CONNECTION_ID();
执行纯 SELECT 后查此表，结果为空；紧接着执行 UPDATE 再查，就能看到刚分配的 TRX_ID。
- 不要依赖
SELECT @@tx_isolation或SELECT @@autocommit来推断是否有 ID -
SHOW ENGINE INNODB STATUS的TRANSACTIONS部分也能看到活跃事务及其 ID，但输出较冗长 - 高并发下大量短生命周期只读事务不占
trx_id空间，这是 InnoDB 控制 ID 膨胀的重要机制
事务ID分配对 MVCC 和性能的实际影响
事务ID 不仅是个编号，它直接影响 Read View 的构造逻辑和 undo log 的清理节奏。只读事务不拿 ID，意味着它不参与当前活跃事务集合（m_ids）快照，也不阻碍 purge 线程回收旧版本。
反过来看，如果业务误将大量报表查询包裹在 START TRANSACTION 中却不加 READ ONLY 提示，InnoDB 可能因无法识别其只读性而分配 ID，导致：
- 不必要的 undo log 增长
- Read View 膨胀，拖慢其他事务的可见性判断
- purge lag 加剧，长期可能引发
Undo log too large类告警
所以，明确声明 START TRANSACTION READ ONLY 不仅是语义清晰，更是释放底层资源的关键动作——哪怕里面只有一条 SELECT。
