mysql中只读事务仍分配事务id，因innodb需用该id支撑mvcc可见性判断、undo log管理及事务上下文初始化，且无法预判后续是否写操作；显式开启即注册事务并分配id。
只读事务为什么也要分配事务ID
MySQL（InnoDB）对每个进入的事务，无论是否真正修改数据，都会立即分配一个唯一的、单调递增的 transaction_id。这不是可选行为，而是事务系统底层设计决定的——transaction_id 不仅用于 MVCC 版本链判断，还承担着事务可见性、回滚段管理、undo log 生命周期控制等职责。
哪怕你只执行 SELECT，只要显式开启事务（比如 BEGIN 或 START TRANSACTION），InnoDB 就会立即注册事务、分配 ID、初始化事务上下文，并在 information_schema.INNODB_TRX 中可见。这是因为 InnoDB 无法在事务开始前预判它后续会不会写——“只读”是语义层面的，而事务 ID 分配是机制层面的刚性动作。
只读事务真的不加锁吗
不一定。默认隔离级别 REPEATABLE READ 下，普通 SELECT 是快照读（snapshot read），不加锁；但以下情况仍会触发真实锁：
-
SELECT ... LOCK IN SHARE MODE→ 加S 锁（共享锁） -
SELECT ... FOR UPDATE→ 加X 锁（排他锁） - 查询涉及唯一索引且满足条件的行 → 可能加
record lock（即使没写） - 范围查询（如
WHERE id BETWEEN 10 AND 20）在 RR 级别下 → 触发gap lock或next-key lock
这些锁一旦加上，就会占用锁资源，出现在 INNODB_LOCKS 和 INNODB_LOCK_WAITS 中，也可能参与死锁检测。
隐式只读事务的陷阱：autocommit=0 + 单条 SELECT
当客户端设置 autocommit = 0 后，每条语句都自动成为独立事务。此时执行一条 SELECT，看似无害，实则：
- 事务状态为
ACTIVE，trx_state显示RUNNING - 事务 ID 已分配，且该 ID 会阻塞 purge 线程清理更老的 undo log（因为 purge 需确保没有更早的活跃事务依赖它）
- 若该事务长时间未结束（比如应用忘了
COMMIT或ROLLBACK），会导致innodb_max_trx_active持续升高，undo 表空间膨胀，甚至拖慢整个实例的 MVCC 性能
这种“空挂事务”在监控中常表现为 TRX_ROWS_AFFECTED = 0 但 TRX_TIME > 300（秒），是最容易被忽略的资源泄漏点。
如何识别和避免只读事务的资源浪费
关键不是禁止只读事务，而是让它们“短、轻、明”：
- 避免长期保持
autocommit = 0；非必要不手动BEGIN，尤其在 ORM 或连接池场景下 - 用
SELECT ... INTO @var替代单纯查结果集，减少客户端与服务端交互开销 - 监控时重点关注：
SELECT * FROM information_schema.INNODB_TRX WHERE TRX_ROWS_AFFECTED = 0 AND TRX_STATE = 'RUNNING' AND TRX_TIME > 60 - 对确定只读的长逻辑，考虑用
SET TRANSACTION READ ONLY显式声明——这能让 InnoDB 跳过部分事务元数据维护（如不分配事务 ID？不，仍会分配，但可减少 undo log 写入）
真正难察觉的，从来不是大事务的锁等待，而是那些安静躺在 INNODB_TRX 里、什么都没干却卡着 purge 和事务 ID 连续性的“幽灵事务”。
