MySQL 事务只读怎么验收：READ ONLY、临时表与写入失败边界

报表接口偶尔会把业务库连接拖进长事务，排查时最容易踩坑的点是：连接标记为只读，不代表所有写入语句都会按同一种逻辑报错。MySQL 的 READ ONLY 事务会限制普通持久化表的写入，但临时表有独立的规则边界；如果连接池在归还连接时没清理干净事务状态，下一个拿到这条连接的请求，很可能直接继承错误的会话设置。

验收只读事务不要只看连接配置。启动事务后分别测试普通 InnoDB 表、临时表和状态变量，再在归还连接前回滚并复查，才能确认限制真的生效且没有泄漏。

先用最小 SQL 看见只读边界

准备一张不会影响线上业务的测试表，或者在隔离环境中使用对应表结构验证。重点不是表里有多少存量数据，而是让普通表和临时表能同时出现在同一个事务中。

CREATE TABLE ro_probe (
  id BIGINT PRIMARY KEY,
  note VARCHAR(64) NOT NULL
) ENGINE=InnoDB;

START TRANSACTION READ ONLY;
SELECT @@transaction_read_only AS read_only;
SELECT * FROM ro_probe WHERE id = 1;
UPDATE ro_probe SET note = 'blocked' WHERE id = 1;
ROLLBACK;

在支持该语法的 MySQL 环境中，状态查询会直接返回只读状态；普通表的更新操作会被服务端直接拒绝。这里不用急着把这类报错当成故障，报错本身就是验收证据：它说明写入限制的约束落在当前事务，完全不需要依赖应用代码主动不执行写入操作。

普通表写入失败，临时表为什么还能写

只读事务的设计目标就是保护持久化落地的数据。临时表只属于当前会话，生命周期和普通持久化表完全不同，因此可以在只读事务中创建、插入和更新。这个特性刚好适合报表过程存储中间结果，不能被误判为“当前事务已经恢复可写状态”。

START TRANSACTION READ ONLY;

CREATE TEMPORARY TABLE ro_tmp (
  id INT PRIMARY KEY,
  value DECIMAL(12, 2)
);

INSERT INTO ro_tmp VALUES (1, 18.50);
UPDATE ro_tmp SET value = 20.00 WHERE id = 1;
SELECT * FROM ro_tmp;

ROLLBACK;

验收时要把两类结果记录在一起：ro_probe 的写入失败，证明持久化表已经被保护；ro_tmp 的写入成功，证明测试已经覆盖了 MySQL 预留的临时表例外规则。如果只测试普通表，后续开发者很容易在报表逻辑里加了临时中间表后，误得出事务完全可写的错误结论。

连接池复用时要查三次

应用侧最危险的问题从来不是单次测试不通过，而是连接归还时状态清理不完整。一个请求启动了只读事务，读取完数据之后没有执行回滚，连接又被下一个请求取走，后续的所有SQL都可能在错误的事务边界里运行。不同连接池的清理配置不完全一致，最好把状态复查逻辑直接写进连接归还的统一流程里。

-- 取出连接后
SELECT @@autocommit, @@transaction_read_only;

-- 只读请求结束
ROLLBACK;

-- 归还前复查
SELECT @@autocommit, @@transaction_read_only;
SHOW WARNINGS;

“三次校验”分别对应取连接时的初始状态、请求执行过程中的只读状态、归还连接前的清理状态。尤其要注意：transaction_read_only 的会话值和当前事务语义不是同一回事，不能只凭单次变量查询就判断整条连接的全生命周期状态。

常见误区：把只读事务当成权限控制

只读事务能替代数据库账号权限吗？

不能。它是事务级的限制规则，适合保护某段专属读取流程；账号层面的 SELECT、INSERT、UPDATE 等权限仍然由数据库授权系统管控。真正的安全边界要靠最小权限账号配置和数据库侧授权规则兜底。

为什么 UPDATE 失败了，临时表却还能 INSERT？

这是 MySQL 官方明确的临时表例外规则。普通表写入失败说明持久化数据已经被保护，临时表可写不代表当前事务已经变回普通可写事务。

只读事务结束后还要执行 ROLLBACK 吗？

建议显式执行。即使当前请求全程只读，显式回滚也能直接结束事务、释放一致性视图，把连接恢复到连接池约定的干净初始状态。

把验收结果写成可回归清单

一次合格的 MySQL READ ONLY 验收至少要留下四项记录：事务启动语句、普通表写入的返回错误、临时表写入的成功结果、连接归还后的状态查询记录。上线前再用连接池连续借还两次连接，确认第二个请求不会继承第一个请求的只读状态。

做完这些校验之后，只读就不是一个模糊的连接标签，而是一组可以重放、可以复现失败、可以反复复查的边界测试规则。出现异常时，先确认事务是否仍在存活、连接是否已经完成回滚，再判断问题到底出在权限配置还是业务SQL本身。

常见问题

SET TRANSACTION READ ONLY 会永久影响这个账号吗？

不会。它只会影响当前事务或者当前会话约定，完全不能替代账号层面的授权规则；事务结束后仍然要按连接池规则复位状态并完成复查。

只读事务里可以创建临时表吗？

可以，临时表属于当前会话，常规的创建、插入和更新操作通常都可以正常执行；普通持久化表的写入操作仍然会被拒绝。

如何确认连接池没有遗留只读状态？

在请求结束时执行 ROLLBACK，归还连接前查询 @@transaction_read_only 和自动提交状态，再连续多次借还连接做一次完整的回归测试。