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-READSET 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 —— 锁范围失控才是并发问题的真正起点。
