只读事务（@transactional(readonly = true)）不直接提速，而是通过向数据库、连接池和orm传递只读语义提示来间接优化：如mysql跳过写锁、hibernate禁用flush、jdbc连接标记setreadonly(true)，但效果依赖驱动支持、无隐式写操作、连接池配置及实际环境验证。
只读事务（@Transactional(readOnly = true)）本身不直接“提速”，它的优化作用是间接的、有条件生效的——关键在于它向底层数据库和连接池传递一个语义提示，让它们有机会做针对性优化。但这个提示是否被采纳、效果如何，取决于数据库类型、驱动实现、连接池配置和实际执行环境。
只读事务的优化原理
设置 readOnly = true 后，Spring 会将该事务标记为只读，并在获取数据库连接时尝试调用 Connection.setReadOnly(true)。部分数据库驱动和连接池会据此做以下动作：
- MySQL（InnoDB）：某些版本下可能跳过写锁申请、减少事务日志开销，但效果有限；若使用
READ COMMITTED隔离级别，MVCC 已天然支持非阻塞读，只读标记影响更小 - PostgreSQL：明确支持只读事务模式，可避免 WAL 写入、禁用某些后台写操作
- HikariCP 等连接池：若配置了
connection-init-sql或启用只读感知，可能复用已标记为只读的空闲连接，降低连接切换成本 - JPA/Hibernate：可能跳过一级缓存脏检查、禁用自动 flush，减少不必要的持久化上下文操作
真正起效的前提条件
只读事务要发挥优化作用，必须满足几个硬性前提：
Java JDK 25
下载
Java JDK 25 来自 OpenJDK 官方归档，版本为 JDK 25，本条下载地址已指向官方 Windows x64 zip 安装包直链，适合调试旧项目或兼容旧版 Java 运行环境。
-
数据库驱动需正确响应：不是所有 JDBC 驱动都实现
setReadOnly(true)的语义，例如旧版 MySQL Connector/J 可能忽略该调用 -
连接池需支持只读路由或复用逻辑：HikariCP 默认不区分只读/读写连接，需配合自定义
DataSource或中间件（如 ProxySQL）才能实现读写分离 - 事务内确实无任何写操作：一旦执行 INSERT/UPDATE/DELETE 或触发隐式写（如序列号生成、临时表写入），部分数据库（如 H2）会立即抛异常，MySQL 则可能静默降级为读写事务，使优化失效
- 避免长查询占用连接：只读事务默认无超时，一个耗时 10 秒的查询会让连接池中一个连接空转 10 秒，反而加剧连接争抢
比 readOnly 更实用的查询优化手段
与其依赖只读事务的不确定优化，不如优先采用更可控、见效更快的方式：
-
对纯查询方法，考虑去掉 @Transactional：JPA 的
findAll()、MyBatis 的selectList等默认不开启事务，连接用完即归还，资源利用率更高 - 显式控制事务边界：仅在真正需要事务一致性的场景（如“查余额 + 扣款”组合）才开启事务，避免把简单查询裹进事务里
-
结合超时与隔离级别：搭配
timeout = 5和isolation = Isolation.READ_COMMITTED，防止慢查询拖垮连接池 - 用数据库原生能力替代：对报表类查询，可走只读从库、物化视图或缓存层（Redis），而非依赖主库事务优化
什么时候可以放心用 readOnly = true
它适合出现在明确、稳定、轻量的只读业务场景中，且你已验证过实际收益：
- 服务层封装的通用查询方法（如
getUserById），调用频次高、逻辑单一、绝无副作用 - 项目已统一使用 PostgreSQL 或新版 MySQL，并通过压测确认开启后 QPS 提升 5% 以上
- 团队已建立规范：所有
@Transactional(readOnly = true)方法都经过 SQL 审计，确保无隐式 DML - 连接池配置了
readOnly = true的专用数据源，或已对接读写分离中间件
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
