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 的
<select></select>标签若配了
fetchSize，可能触发流式查询，绕过事务上下文 最稳妥做法：在
@Transactional注解中明确指定
isolation，让 Spring 在获取连接后立即调用
Connection.setTransactionIsolation()，而非依赖 SQL 手动执行 配置文件里的
transaction_isolation只管新连接起点，真实事务行为由会话变量、驱动行为、框架封装层层叠加决定。调试时优先查
@@transaction_isolation，而不是翻 my.cnf。
