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，强制串行化，性能损耗大，极少用于生产
如何验证当前连接的隔离级别？别只信配置文件
配置文件写对了 ≠ 当前连接生效了。最可靠的方式是直接查变量值，尤其在连接池场景下，应用可能复用连接并手动改过隔离级别。
