MySQL默认隔离级别为REPEATABLE READ，但通过间隙锁+行锁规避幻读而非完全阻止，与标准SQL定义不一致；READ COMMITTED支持半一致性读，SERIALIZABLE易引发死锁且不能替代应用层并发控制。
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(*) 不锁表。这种地方必须靠唯一索引或应用层协调。
