read committed是多数web业务的合理默认选择，因其避免了repeatable read的间隙锁开销和死锁风险，且在row格式binlog下更利于主从一致性；但需在事务开始前显式设置，不可在活跃事务中修改。
READ COMMITTED 是大多数 Web 业务的合理默认选择，不是因为“它够好”，而是因为 REPEATABLE READ（MySQL 默认）在多数场景下引入了不必要的锁开销和死锁风险，而 SERIALIZABLE 几乎不可用。
为什么 SET TRANSACTION ISOLATION LEVEL READ COMMITTED 要在事务开始前执行
MySQL 明确禁止在活跃事务中修改隔离级别，否则报错：Can’t change transaction isolation level when a transaction is active。这个限制不是设计疏漏，而是底层 MVCC 快照在事务启动时已确定——后续改级别无法回溯重建快照。
实操建议：
- 在应用层连接池初始化后、执行第一条 SQL 前，显式执行
SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED - 不要依赖 ORM 自动设置；例如 Spring 的
@Transactional(isolation = Isolation.READ_COMMITTED)在 MySQL 上仍需确认驱动是否真正下发了 SET 语句 - 若使用连接复用（如 PooledConnection），每次获取连接后都应重置隔离级别，避免被上一个使用者污染
REPEATABLE READ 下的间隙锁（Gap Lock）容易卡住 INSERT
这是线上最常被忽略的性能陷阱：在 REPEATABLE READ 下，SELECT ... FOR UPDATE 或 UPDATE ... WHERE 带范围条件时，InnoDB 不仅锁匹配行，还会锁住索引间隙。比如 SELECT * FROM orders WHERE status = 'pending' FOR UPDATE，即使表里当前没有 status = 'pending' 的记录，也可能锁住整个 status 索引的空隙，导致新插入 pending 订单被阻塞。
对比 READ COMMITTED：
- 同样语句只锁定实际命中的行（Record Lock），不锁间隙
- 代价是：两次查询之间可能有新记录插入（幻读），但电商下单、支付确认等场景通常不依赖“两次查结果集完全一致”
- 没有合适索引时，
REPEATABLE READ可能升级为全表间隙锁，而READ COMMITTED至少还能走主键或唯一索引的行锁
主从一致性与 binlog_format = ROW 的隐性关联
MySQL 8.0+ 默认 binlog_format = ROW，此时 READ COMMITTED 对主从复制更友好。原因在于：ROW 格式记录的是每行变更后的镜像，而 REPEATABLE READ 的间隙锁行为可能导致从库回放时加锁顺序不同，引发死锁或延迟。
如果你的业务已开启 GTID + ROW + 半同步复制，却还在用 REPEATABLE READ，要特别注意以下两点：
- 从库
SHOW PROCESSLIST中频繁出现Waiting for table metadata lock或Locked，很可能是间隙锁传播到了从库 -
READ COMMITTED下普通SELECT是快照读（不加锁），不会干扰 DDL，而REPEATABLE READ的长事务可能阻塞ALTER TABLE
真正需要 REPEATABLE READ 的场景极少，比如财务对账系统要求“导出报表期间所有数据版本冻结”。但即便如此，也建议用 SELECT ... INTO OUTFILE + 显式快照（START TRANSACTION WITH CONSISTENT SNAPSHOT）替代全局隔离级别切换。复杂点永远在锁行为与业务语义是否对齐，而不是“选个高隔离级别就更安全”。
