MySQL默认隔离级别是REPEATABLE READ，因其MVCC实现需配合临键锁来平衡并发与一致性，虽能避免脏读和不可重复读，但在范围查询并发插入时仍可能产生幻读。
MySQL 默认隔离级别是什么，为什么它不是 READ COMMITTED
MySQL（InnoDB）默认是 REPEATABLE READ，不是大多数其他数据库（如 PostgreSQL、Oracle）默认的 READ COMMITTED。这不是疏忽，而是为配合其 MVCC 实现和减少锁竞争做的权衡。
-
REPEATABLE READ下，普通SELECT是快照读（不加锁），能避免脏读和不可重复读；而SELECT ... FOR UPDATE或UPDATE会用临键锁（Next-Key Lock），在多数场景下也隐式防止幻读——这是 MySQL 的特殊优化，和 SQL 标准定义略有差异 - 如果你误以为“可重复读就绝对没幻读”，会在范围查询 + 并发插入时踩坑：比如事务 A 执行
SELECT * FROM t WHERE age > 25 FOR UPDATE，事务 B 仍可能插入age = 30的新行并提交，A 再查会“看到新行”，这就是幻读（除非你显式加SELECT ... LOCK IN SHARE MODE或升级到SERIALIZABLE） - 切换隔离级别要全局/会话级明确设置：
SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED；仅靠应用层框架配置（如 Spring 的@Transactional(isolation = ...)）可能被连接池复用旧会话覆盖
怎么验证当前事务看到的是哪个版本的数据
不能只看 SELECT @@transaction_isolation，那只是隔离级别声明；真正决定“看到什么”的是 MVCC 快照 + 当前事务 ID + 行的 DB_TRX_ID 和 DB_ROLL_PTR 隐藏字段。
- 用
SELECT * FROM information_schema.INNODB_TRX查当前活跃事务的TRX_ID和TRX_STARTED时间，结合SELECT * FROM information_schema.INNODB_LOCKS看锁等待关系 - 开启
innodb_status_output_locks = ON后，执行SHOW ENGINE INNODB STATUS可看到更细粒度的锁信息，包括哪些间隙被锁住 - 想确认某条记录是否被其他事务修改过？查它的隐藏字段（需用
SELECT * FROM t EXTENDED+SHOW WARNINGS解析执行计划，或直接查INFORMATION_SCHEMA.INNODB_BUFFER_PAGE，但生产环境慎用）
什么时候必须用 SERIALIZABLE，以及它真能解决所有问题吗
SERIALIZABLE 不是“万能开关”，它是通过自动将每个普通 SELECT 转成 SELECT ... LOCK IN SHARE MODE 来实现的，本质是强制读写串行化。
- 它确实能堵死脏读、不可重复读、幻读，但代价是并发能力断崖式下降——哪怕两个事务只读不同行，也可能因共享锁冲突而排队
- 常见误用：在高并发订单创建场景中，为防超卖把整个商品表
SELECT ... FOR UPDATE改成SERIALIZABLE事务，结果所有下单请求全卡在锁队列里 - 替代方案往往更优：用乐观锁（
version字段 +WHERE version = ?）处理更新冲突；或拆分热点（如按商品类目分库分表），比硬上串行化更可持续
间隙锁（Gap Lock）和临键锁（Next-Key Lock）到底锁了什么
这是 InnoDB 在 REPEATABLE READ 下防幻读的核心机制，但也是死锁高发区。
- 间隙锁锁的是索引之间的“空隙”，比如索引值为
(1, 5, 10)，那么(5, 10)就是一个间隙；执行SELECT * FROM t WHERE id BETWEEN 6 AND 9 FOR UPDATE会锁住这个间隙，阻止插入id=7的行 - 临键锁 = 记录锁（Record Lock）+ 间隙锁，即锁住记录本身及其前面的间隙；例如
WHERE id = 5，实际锁住的是(1,5]（假设前一条是 1） - 唯一等值查询（
WHERE pk = ?）且记录存在时，InnoDB 会退化为仅加记录锁，不锁间隙——这是关键优化点，但若pk不存在，则仍会锁间隙（防止幻插入）
MySQL 的隔离级别不是配置完就一劳永逸的开关，它和你的索引设计、SQL 写法、事务粒度深度耦合。最容易被忽略的一点是：即使在 REPEATABLE READ 下，没有索引的 WHERE 条件会导致全表扫描 + 全表间隙锁，瞬间让并发能力归零。
