mysql的事务隔离级别与并发控制的选择_技术教程

MySQL默认隔离级别是REPEATABLE-READ，通过MVCC+Next-Key Lock避免脏读和不可重复读，但未真正解决幻读；高并发场景推荐READ-COMMITTED，需确保WHERE条件命中索引以避免锁升级。

MySQL 默认隔离级别是 REPEATABLE-READ，但不是所有场景都适合

MySQL 8.0+ 默认使用 REPEATABLE-READ，它通过 MVCC + Next-Key Lock 实现可重复读，能避免脏读、不可重复读，但**不解决幻读**（只是用间隙锁“掩盖”了现象）。如果你的应用大量依赖 SERIALIZABLE 语义（比如金融对账、库存强一致性扣减），默认级别反而可能掩盖死锁或锁等待问题。

OLTP 系统中，READ-COMMITTED 更常见：降低锁粒度，减少锁冲突，配合 binlog 格式 ROW 也能保证主从一致性
报表类查询或只读分析任务，可显式加 SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED（需确认业务能容忍脏读）
SERIALIZABLE 在 MySQL 中会将所有普通 SELECT 隐式转为 SELECT ... LOCK IN SHARE MODE，极易引发锁等待，不建议全局设置

如何查看和修改当前事务隔离级别

隔离级别作用域分 session 和 global，修改 global 不影响已有连接，且需要 SUPER 权限。生产环境应优

先用 session 级别控制，避免误影响其他应用连接。

SELECT @@transaction_isolation;
-- 返回类似：REPEATABLE-READ
SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED;
-- 当前连接后续事务生效
SET GLOBAL TRANSACTION ISOLATION LEVEL READ COMMITTED;
-- 新建连接生效（需 SUPER 权限）

注意：@@tx_isolation 是旧变量名（5.7 及以前），MySQL 8.0+ 应统一用 @@transaction_isolation；变量名不带引号，否则报错 Unknown system variable。

幻读在 REPEATABLE-READ 下为什么“看不出来”

因为 MySQL 的 REPEATABLE-READ 用了 Next-Key Lock（记录锁 + 间隙锁），执行 SELECT ... WHERE id > 10 时，不仅锁住匹配的行，还锁住 (10, +∞) 这个范围，新插入的记录会被阻塞。但这不是标准 SQL 定义的“解决幻读”，而是用锁压制了并发插入——一旦你改用 READ-COMMITTED，间隙锁失效，幻读立刻暴露。

验证方式：在事务 A 中 SELECT * FROM t WHERE id > 10，事务 B 插入 id=15 并提交，在 A 中再次执行相同 SELECT —— REPEATABLE-READ 下查不到新行（间隙锁阻止了 B 提交），READ-COMMITTED 下能看到
真正要规避幻读逻辑，不能只靠隔离级别，得结合 SELECT ... FOR UPDATE 显式加锁，或用唯一约束 + 插入前检查

并发更新时，UPDATE 的 WHERE 条件是否命中索引决定锁行为

这是最容易被忽略的性能与死锁根源。MySQL 的行锁（Record Lock）只在索引上生效；若 UPDATE 的 WHERE 条件无法走索引，会退化为表锁（或全聚簇索引扫描锁），极大增加冲突概率。

UPDATE orders SET status = 'shipped' WHERE user_id = 123;
-- 如果 user_id 没有索引，InnoDB 会锁住整个聚簇索引，所有并发 UPDATE 都排队

用 EXPLAIN FORMAT=tree 确认 UPDATE 是否走了索引
高并发写场景下，尽量让 WHERE 条件命中唯一索引或联合索引最左前缀
避免在事务中先 SELECT 再 UPDATE（“读-改-写”），改用原子操作如 UPDATE ... SET x = x + 1 WHERE id = ?

隔离级别再高，也救不了没索引的 UPDATE —— 锁范围失控才是并发问题的真正起点。