在mysql的InnoDB引擎中，事务分为读写事务和只读事务两类，不少开发者会产生一个误区，认为只读事务只做查询操作，不会修改数据，因此不会消耗额外的系统资源。但实际上只读事务在运行期间依然会产生一定的资源开销，不过InnoDB也针对只读事务设计了一系列优化方案，尽可能降低这类开销对系统性能的影响。
只读事务为什么会消耗资源
要理解只读事务的资源消耗，首先需要了解InnoDB事务的基础运行机制，即使事务没有写操作，以下环节依然会产生开销：
1. 事务状态维护成本
InnoDB需要为每个活跃事务维护对应的状态信息，包括事务的启动时间、事务的隔离级别、当前的事务状态等。这些信息会存储在内存的事务链表中，即使事务是只读的，只要事务没有提交或回滚，这些状态信息就会一直占用内存空间。
2. 一致性视图构建开销
在可重复读（RR）和读已提交（RC）隔离级别下，事务启动时会构建一致性视图（Read View），用于判断哪些数据版本对当前事务可见。构建一致性视图需要遍历当前活跃的事务列表，获取活跃事务的最大最小事务ID，这个过程本身会消耗一定的CPU资源，同时一致性视图的相关信息也会占用内存。
3. 事务ID的分配与引用
默认情况下，InnoDB会为每个启动的事务分配一个唯一的事务ID，事务ID会参与可见性判断、undo日志的关联等流程。即使事务是只读的，只要分配了事务ID，就需要在相关数据结构中进行记录和维护，产生额外的开销。
4. 潜在的事务链表操作
事务启动和结束时，都需要将自己加入或移出全局的活跃事务链表，这个链表的操作需要加锁保证线程安全，即使只读事务也会参与这个流程，带来一定的锁竞争开销。
InnoDB对只读事务的优化策略
为了减少只读事务的资源消耗，InnoDB从多个维度做了针对性的优化，以下是核心的优化点：
1. 延迟事务ID分配
对于显式声明为只读的事务，InnoDB不会在事务启动时就分配事务ID，只有当事务第一次需要访问需要事务ID参与判断的数据时，才会分配事务ID。如果整个事务过程中都没有触发这个逻辑，就不会分配事务ID，减少了事务ID相关的维护开销。
可以通过以下方式显式声明只读事务：
-- 方式1：启动事务时指定只读 START TRANSACTION READ ONLY; SELECT * FROM user WHERE id = 1; COMMIT; -- 方式2：设置会话级别的只读属性 SET SESSION TRANSACTION READ ONLY; START TRANSACTION; SELECT * FROM order WHERE user_id = 1; COMMIT;
2. 避免不必要的undo日志写入
undo日志主要用于事务回滚和MVCC的版本控制，只有写事务才会产生undo日志。对于只读事务，InnoDB不会为其分配undo段，也不会写入任何undo日志，减少了磁盘IO和内存的开销。
3. 减少锁相关的开销
只读事务默认不会对读取的数据加排他锁，在常见的隔离级别下，普通查询使用的是一致性非锁定读，不需要加共享锁，避免了锁的获取、释放以及锁竞争带来的开销。只有在显式使用SELECT ... FOR SHARE这类语句时，才会加相应的锁。
4. 自动判断事务类型
如果事务启动后没有执行过写操作，InnoDB会自动将其识别为只读事务，在事务提交时走只读事务的提交流程，不需要执行写事务的回滚段清理、redo日志刷盘等额外操作，加快提交速度，减少资源占用。
5. 一致性视图的轻量构建
对于只读事务，InnoDB在构建一致性视图时，会省略一些写事务需要的额外信息，只保留可见性判断必需的最小信息集合，减少内存占用和构建视图的CPU消耗。
如何合理使用只读事务
在实际开发中，可以通过以下方式进一步降低只读事务的资源消耗：
- 对于纯查询的业务逻辑，显式使用
START TRANSACTION READ ONLY启动事务，让InnoDB明确识别事务类型，触发更多优化逻辑。 - 如果业务不需要事务的隔离性保证，比如只是简单的单条查询，可以不启动事务，直接执行查询语句，避免事务状态维护的开销。
- 合理设置事务的隔离级别，如果业务可以接受不可重复读，使用读已提交隔离级别，相比可重复读级别，一致性视图的维护开销会更低。
验证只读事务优化的效果
我们可以通过对比普通事务和只读事务的资源消耗，来验证优化的效果，以下是简单的测试示例：
-- 查看当前事务相关的状态变量 SHOW STATUS LIKE 'Innodb_trx%'; -- 启动普通事务执行查询 START TRANSACTION; SELECT * FROM test_table LIMIT 1; COMMIT; -- 启动只读事务执行查询 START TRANSACTION READ ONLY; SELECT * FROM test_table LIMIT 1; COMMIT;
通过监控事务执行期间的Innodb_trx相关变量，以及系统的CPU、内存占用，可以明显看到只读事务的相关开销要低于普通事务。
总的来说，只读事务虽然会产生一定的资源消耗，但InnoDB的优化已经将其开销降到了很低的水平，在需要保证查询一致性的场景下，合理使用只读事务不会对系统性能造成明显影响。