MySQL默认隔离级别为REPEATABLE READ，当前会话级别可通过SELECT @@transaction_isolation（8.0+）或@@tx_isolation（5.7-）查看；修改需用SET SESSION，不可在事务中更改，全局修改需SUPER权限且不影响已有会话。
查看当前会话的事务隔离级别
MySQL 默认隔离级别是 REPEATABLE READ，但实际生效的可能是全局、会话或事务级设置，优先级为：事务级 > 会话级 > 全局级。直接查 SELECT @@tx_isolation 或 SELECT @@transaction_isolation（8.0+ 推荐后者）能快速确认当前会话值。
常见错误现象：SELECT @@tx_isolation 返回空或报错——这是 MySQL 8.0+ 已弃用该变量名，必须改用 @@transaction_isolation；另外，如果在未开启事务时查，返回的是会话默认值，不代表当前活跃事务的实际级别。
- MySQL 5.7 及以前用
SELECT @@tx_isolation - MySQL 8.0+ 必须用
SELECT @@transaction_isolation - 若连接刚建立还没执行任何事务，该值反映的是会话初始化时继承的隔离级别
修改会话级隔离级别（最常用）
开发和调试中绝大多数场景只需改当前连接的隔离级别，不影响其他会话。用 SET SESSION TRANSACTION ISOLATION LEVEL 即可，语法严格，不能省略 SESSION 或写成 SET GLOBAL 误操作。
使用场景：测试脏读/幻读行为、验证 ORM 框架是否按预期设定了隔离级别、临时绕过长事务锁竞争。
- 正确写法：
SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED - 错误写法：
SET TRANSACTION ISOLATION LEVEL READ COMMITTED（缺SESSION，MySQL 会当作“下一个事务生效”，但当前会话后续事务才生效，容易误判） - 不支持动态设置为
READ UNCOMMITTED的存储引擎（如 InnoDB 支持，MyISAM 不支持事务，设了也无效）
修改全局隔离级别（谨慎！）
SET GLOBAL TRANSACTION ISOLATION LEVEL 会影响之后所有新建立的连接，但**不会改变已存在的会话**。线上环境极少需要，除非集群统一升级隔离策略且能接受滚动重启连接。
性能与兼容性影响：全局设为 READ COMMITTED 后，InnoDB 不再使用间隙锁（gap lock），可降低死锁概率，但也可能让原本被间隙锁挡住的幻读问题暴露出来；设为 SERIALIZABLE 则自动将所有普通 SELECT 转为加锁读，QPS 显著下降。
- 必须有
SUPER权限才能执行SET GLOBAL - 修改后需检查
SELECT @@global.transaction_isolation确认生效 - 配置文件里设
transaction-isolation = READ-COMMITTED更稳妥，避免重启后丢失
事务内临时覆盖隔离级别（不支持）
MySQL **不允许**在已开启的事务中修改隔离级别。一旦执行了 BEGIN 或 START TRANSACTION，再执行 SET TRANSACTION ISOLATION LEVEL … 会直接报错：ERROR 1568 (25001): Transaction characteristics can't be changed while a transaction is in progress。
这意味着：ORM 如 Django 或 SQLAlchemy 如果在事务开始后才调用 set_transaction_isolation()，会直接抛异常；必须在 BEGIN 前设置好会话级隔离级别，或在事务启动语句里显式指定：
- 正确方式：
SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED; START TRANSACTION; - 或合并写：
START TRANSACTION ISOLATION LEVEL READ COMMITTED;（MySQL 8.0.14+ 支持） - 旧版本只能靠会话预设，没法“按事务定制”
真正麻烦的是跨连接复用连接池时，会话隔离级别可能被前一个请求改掉又没重置——别依赖连接池自动恢复，每次获取连接后主动 SET SESSION 一次更可靠。
