读已提交是大多数 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 = '2024-05-01'; -- 同一事务内再次查询，必须和第一次完全一致 SELECT COUNT(*) FROM trade_log WHERE date = '2024-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更可控、更轻量
真正需要串行逻辑时，优先考虑应用层分布式锁 + 幂等设计，而不是把压力扔给数据库隔离级别。
隔离级别不是越严越好，关键在匹配业务语义。最容易被忽略的一点是：很多“以为需要可重复读”的场景，其实只是没做好应用层缓存刷新或版本控制——先检查代码里是不是把“查一次、用三次”的逻辑硬塞进了事务，再决定要不要调数据库的隔离级别。
