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