mysql中只读事务必须用start transaction read only，begin不支持修饰符；read only仅限制对其他事务可见表的修改，不影响临时表、变量赋值等操作，且需配合repeatable read隔离级别才能使with consistent snapshot生效。
只读事务必须用 START TRANSACTION READ ONLY，BEGIN 不支持修饰符
MySQL 中只有 START TRANSACTION 语句允许附加 READ ONLY 修饰符；BEGIN 或 BEGIN WORK 是纯语法糖，不接受任何参数。如果你写 BEGIN READ ONLY，MySQL 会直接报错：ERROR 1064 (42000): You have an error in your SQL syntax。
常见误操作包括：
- 把
READ ONLY当成独立命令执行（如先BEGIN再SET TRANSACTION READ ONLY）——MySQL 不支持该语法 - 在事务已开启后试图动态切换为只读模式——事务访问模式只能在启动时确定，运行中不可更改
- 混淆用户级只读权限（
GRANT SELECT）和事务级只读模式（READ ONLY），二者完全无关
READ ONLY 的实际限制范围很窄，不是“禁止所有写”
READ ONLY 仅阻止对**其他事务可见的表**进行修改或加锁，比如普通 InnoDB 表、MyISAM 表。但它不限制以下操作：
- 对
CREATE TEMPORARY TABLE创建的临时表执行INSERT/UPDATE/DELETE - 执行
SELECT ... INTO @var、变量赋值、存储过程内部逻辑 - 调用不修改数据的函数（如
NOW()、UUID()）
也就是说，READ ONLY 主要是给优化器提供提示，让 InnoDB 跳过某些锁检查和日志写入，提升只读查询性能。它不是安全隔离机制，也不能替代权限控制。
搭配 WITH CONSISTENT SNAPSHOT 时要注意隔离级别
WITH CONSISTENT SNAPSHOT 只在 REPEATABLE READ 隔离级别下生效。如果当前会话是 READ COMMITTED 或更低，MySQL 会忽略该修饰符并发出警告（Warning 1687: WITH CONSISTENT SNAPSHOT is ignored when @@transaction_isolation is not REPEATABLE-READ）。
MySQL 9.6.0是面向Linux平台的2026年创新版本，核心架构迎来重大革新。其将外键约束与级联操作从InnoDB引擎层上移至SQL层，确保所有数据变更均被完整记录至Binlog，彻底解决了CDC（变更数据捕获）与主从复制中的数据不一致难题。此外，该版本引入container_aware启动选项以原生适配容器环境，并对审计日志进行了组件化重构，为追求极致数据一致性与云原生体验的开发者提供了全新选择。
所以正确写法是：
SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ; START TRANSACTION READ ONLY, WITH CONSISTENT SNAPSHOT;
如果省略隔离级别设置，且全局默认不是 REPEATABLE READ，快照可能不会按预期建立。
只读事务里执行写操作会立刻报错，但错误类型容易误导人
一旦在 READ ONLY 事务中执行 UPDATE 或 INSERT，MySQL 返回的错误是：ERROR 1792 (25006): Cannot execute statement in a READ ONLY transaction。
这个错误和从库 read_only = ON 导致的 ERROR 1290 完全不同，不要混淆。前者是事务级限制，后者是实例级系统变量限制。两者可共存，但触发条件和作用域完全不同。
特别注意：如果应用使用连接池且未显式关闭事务，一个被遗忘的只读事务可能长期占用连接，导致后续语句持续失败，排查时容易忽略事务状态本身。
