mysql存储引擎的事务隔离级别如何设置_mysql配置说明

mysql事务隔离级别可在配置文件全局设置或SQL动态调整：SET GLOBAL影响新连接，默认需SUPER权限；SET session只改当前会话。InnoDB实际支持READ-COMMITTED、REPEATABLE-READ（默认）、SERIALIZABLE，READ-UNCOMMITTED被降级为READ-COMMITTED。验证用select @@transaction_isolation；spring中应优先使用@Transactional注解而非手动SQL设置。

MySQL 事务隔离级别在哪设置？全局 vs 会话级

MySQL 的事务隔离级别既可以在启动时通过配置文件全局设定，也可以在连接建立后用 SQL 语句动态调整。关键区别在于作用范围：SET GLOBAL tx_isolation 影响新连接的默认值，而 SET SESSION tx_isolation 只改变当前连接的行为——已有事务不受影响。

• tx_isolation 是旧参数名（5.7 及以前），8.0+ 推荐用 transaction_isolation，两者功能一致但后者是标准 SQL 兼容写法
• 修改全局级别需要 SUPER 权限，且不会回滚正在运行的事务；修改会话级别只需普通用户权限
• 配置文件中写 transaction_isolation = READ-COMMITTED，注意必须用短横线分隔，不能写成下划线或驼峰
• 重启 MySQL 后，全局配置才生效；会话级设置在断连后自动失效

InnoDB 支持哪些隔离级别？READ-UNCOMMITTED 实际不可用

InnoDB 理论上支持全部四种 ANSI 标准隔离级别，但 READ-UNCOMMITTED 在实际行为中被降级为 READ-COMMITTED——因为 InnoDB 的多版本并发控制（MVCC）机制天然不维护“未提交”的版本快照，无法真正实现脏读。

• READ-COMMITTED：每次 SELECT 都生成新一致性视图，可避免脏读和不可重复读（非幻读）
• REPEATABLE-READ（InnoDB 默认）：事务内所有 SELECT 复用同一快照，能避免脏读、不可重复读，但幻读需靠间隙锁（gap lock）或 SELECT ... for UPDATE 显式加锁抑制
• SERIALIZABLE：隐式将所有普通 SELECT 转为 SELECT ... LOCK IN SHARE MODE，强制串行化，性能损耗大，极少用于生产

如何验证当前连接的隔离级别？别只信配置文件

配置文件写对了 ≠ 当前连接生效了。最可靠的方式是直接查变量值，尤其在连接池场景下，应用可能复用连接并手动改过隔离级别。

• 查当前会话：SELECT @@transaction_isolation; 或 SELECT @@tx_isolation;
• 查全局默认值：SELECT @@global.transaction_isolation;
• 注意返回值格式：MySQL 8.0+ 返回类似 REPEATABLE-READ 的字符串，不是数字；5.7 返回如 REPEATABLE-READ 或 READ-COMMITTED，大小写敏感
• 如果返回 NULL，说明该连接尚未显式设置，正使用全局默认值

spring boot 应用里改隔离级别，为什么 SQL 不生效？

Spring 的 @Transactional(isolation = Isolation.REPEATABLE_READ) 是声明式控制，底层仍依赖 JDBC 连接的实际能力。常见失效原因不是配置错，而是连接池或驱动层拦截/覆盖了设置。

• HikariCP 默认启用 isolateInternalQueries = false，但若设为 true，会在执行内部查询前重置隔离级别，导致你的 SET SESSION 被忽略
• MySQL Connector/J 8.0+ 驱动默认开启 useServerPrepStmts=true，某些旧版驱动在预编译语句中会丢弃隔离级别变更
• mybatis 的 标签若配了 fetchSize，可能触发流式查询，绕过事务上下文
• 最稳妥做法：在 @Transactional 注解中明确指定 isolation，让 Spring 在获取连接后立即调用 Connection.setTransactionIsolation()，而非依赖 SQL 手动执行

配置文件里的 transaction_isolation 只管新连接起点，真实事务行为由会话变量、驱动行为、框架封装层层叠加决定。调试时优先查 @@transaction_isolation，而不是翻 my.cnf。