mysql的事务隔离级别与并发控制的选择

来源：这里教程网时间：2026-02-28 20:40:38 作者：

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
<p>SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED;
-- 当前连接后续事务生效</p><p>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 —— 锁范围失控才是并发问题的真正起点。