MySQL 默认隔离级别是 REPEATABLE READ，但行为和标准 SQL 不完全一致
MySQL InnoDB 的
REPEATABLE READ并不阻止幻读（Phantom Read）的典型表现，而是通过间隙锁（Gap Lock）+ 行锁来规避——这意味着在范围查询时会锁住不存在但“可能插入”的记录区间。这不是 bug，是 InnoDB 的优化实现，但容易让人误以为它等同于标准 SQL 的
REPEATABLE READ。
验证当前会话隔离级别：
SELECT @@transaction_isolation;注意：5.7+ 返回类似
'REPEATABLE-READ'（带连字符），8.0+ 默认为
'REPEATABLE-READ'且支持
READ-COMMITTED作为可选值。
READ UNCOMMITTED：能读到其他事务未提交的修改（脏读），极少用，仅调试或极低一致性要求场景
READ COMMITTED：每次
SELECT都生成新快照，避免脏读，但不可重复读（同一事务内两次查同一行，值可能不同）
REPEATABLE READ：事务启动时创建一致性视图（consistent read view），后续所有
SELECT都复用该快照，解决不可重复读；但范围查询仍可能因并发插入出现“幻影行”，InnoDB 用间隙锁压制
SERIALIZABLE：最高级别，隐式地为所有
SELECT加共享锁（等价于
SELECT ... LOCK IN SHARE MODE），写操作会阻塞读，读也会阻塞写，极易死锁
如何安全地切换隔离级别？别只改 session，小心应用层失效
设置会话级隔离级别：
SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED;但要注意： Spring Boot 的
@Transactional(isolation = Isolation.READ_COMMITTED)会在事务开启前执行
SET TRANSACTION ISOLATION LEVEL，优先级高于 session 级设置 连接池（如 HikariCP）可能复用连接，若上一个事务没显式重置，新事务可能继承旧隔离级别 MySQL 8.0+ 支持全局设置：
SET GLOBAL TRANSACTION ISOLATION LEVEL READ COMMITTED;，但不会影响已存在的连接 PHP PDO、Python MySQLdb 等客户端通常不自动同步服务端隔离级别变更，需手动调用
SET
READ COMMITTED 下的“半一致性读”对 UPDATE 很关键
在
READ COMMITTED下，
UPDATE或
DELETE语句不是基于事务启动时的快照，而是“看到最新已提交版本 + 满足 WHERE 条件的行”，即所谓半一致性读（semi-consistent read）。这能减少锁等待，但也带来副作用： 同一事务中先
SELECT再
UPDATE，可能更新到别的事务刚提交的行（而你 SELECT 时还没看到） 如果业务依赖“查出来再改”，必须加
SELECT ... FOR UPDATE强制加锁，否则逻辑可能错乱 InnoDB 在
READ COMMITTED下不使用间隙锁（除外键检查和唯一索引冲突场景），所以范围
UPDATE不会锁住间隙，幻读风险更高
SERIALIZABLE 不等于“绝对安全”，反而容易掩盖设计问题
启用
SERIALIZABLE后，普通
SELECT会变成锁读，看似杜绝所有并发问题，但代价巨大： 高并发下大量锁竞争，TPS 断崖下降，超时和死锁概率飙升 ORM 如 Hibernate/JPA 可能因隐式 SELECT 被锁住，导致整个请求卡住 它不能替代应用层幂等、乐观锁或分布式锁——比如扣库存仍需
UPDATE stock SET count = count - 1 WHERE id = ? AND count >= 1这类条件更新 真正需要串行化逻辑（如生成单号、抢购）应拆出独立服务或用 Redis + Lua 做原子控制，而不是靠数据库隔离级别硬扛
最常被忽略的一点：隔离级别只约束“读写可见性”，不保证业务逻辑正确。哪怕用了
SERIALIZABLE，两个事务同时执行
SELECT COUNT(*)再插入，依然可能违反唯一约束——因为
COUNT(*)不锁表。这种地方必须靠唯一索引或应用层协调。
