17370845950

读已提交是大多数OLTP业务默认起点，因其避免脏读且无间隙锁开销；可重复读适用于报表对账等需事务内快照一致场景；串行化仅限离线校验，线上应避免。

读已提交（READ COMMITTED）为什么是大多数业务的默认起点

绝大多数 OLTP 业务（如订单、支付、库存扣减）不需要可重复读的强一致性，但必须避免脏读。MySQL 默认的 REPEATABLE READ 在某些场景下反而带来隐性成本——比如间隙锁导致的锁冲突升高、主从延迟加剧，而 READ COMMITTED 能显著缓解这些问题。

实操建议：

• 确认业务逻辑不依赖“同一事务内多次 SELECT 结果一致”这个语义（例如没有基于第一次查询结果做条件判断后再更新）
• 在 my.cnf 中设置 transaction_isolation = 'READ-COMMITTED'，或连接后执行 SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED
• 注意：此级别下 UPDATE ... WHERE 仍会加行锁（非间隙锁），但不会像 REPEATABLE READ 那样自动升级为 Next-Key Lock
• Binlog 格式必须为 ROW，否则在 READ COMMITTED 下可能产生主从不一致（尤其涉及 UPDATE+子查询时）

可重复读（REPEATABLE READ）该用在哪些真实场景

REPEATABLE READ 不是“过时设定”，它解决的是明确需要事务内快照一致性的场景，比如报表生成、对账核验、分页查询中防止幻读干扰总页数计算。

但要注意它的代价：

• 默认启用间隙锁（Gap Lock），在 WHERE id > 100 这类范围条件上会锁住不存在的记录区间，容易引发死锁
• 高并发写入时，InnoDB 的 MVCC 版本链更长，undo log 清理压力增大，可能拖慢 purge 线程
• 如果应用层做了重试逻辑（如乐观锁失败后重查再更新），REPEATABLE READ 的快照可能导致“查到旧值 → 更新失败 → 重试仍查旧值”的循环

典型适用案例：

START TRANSACTION;
SELECT SUM(amount) FROM trade_log WHERE date = '2025-05-01';
-- 同一事务内再次查询，必须和第一次完全一致
SELECT COUNT(*) FROM trade_log WHERE date = '2025-05-01' AND status = 'success';
COMMIT;

如何识别当前事务实际生效的隔离级别

不要只看配置文件或初始化参数——MySQL 允许会话级覆盖，且某些客户端驱动（如旧版 PyMySQL、某些 JDBC 连接池）会在建连时悄悄重设隔离级别。

排查方法：

• 登录后立即执行 SELECT @@transaction_isolation; 或 SELECT @@tx_isolation;（后者在 8.0+ 已弃用但仍可用）
• 在事务中执行 SELECT * FROM information_schema.INNODB_TRX;，观察 TRX_ISOLATION_LEVEL 字段
• 使用 Percona Toolkit 的 pt-deadlock-logger 抓取死锁日志时，其中的 isolation level 行能反推事务启动时的实际级别

串行化（SERIALIZABLE）几乎不该在业务库中启用

SERIALIZABLE 会让所有普通 SELECT 隐式加上共享锁（相当于自动改写为 SELECT ... LOCK IN SHARE MODE），本质上退化为锁表行为。它只适合极低频、强一致性要求的离线校验脚本，比如财务关账前的全量数据比对。

线上业务踩坑示例：

• 一个简单 SELECT id FROM user WHERE status = 1 LIMIT 1 在 SERIALIZABLE 下会阻塞所有对该范围的 INSERT/UPDATE，吞吐直接归零
• Spring 的 @Transactional(isolation = Isolation.SERIALIZABLE) 若未配超时，极易引发线程池耗尽
• 即使只在单条 SQL 上加 FOR UPDATE，也比全局设 SERIALIZABLE 更可控、更轻量

真正需要串行逻辑时，优先考虑应用层分布式锁 + 幂等设计，而不是把压力扔给数据库隔离级别。

隔离级别不是越严越好，关键在匹配业务语义。最容易被忽略的一点是：很多“以为需要可重复读”的场景，其实只是没做好应用层缓存刷新或版本控制——先检查代码里是不是把“查一次、用三次”的逻辑硬塞进了事务，再决定要不要调数据库的隔离级别。