MySQL默认隔离级别REPEATABLE READ通过MVCC+间隙锁防幻读，但仅对当前读生效；普通SELECT是快照读、不加锁；依赖可重复读语义需显式加锁；READ COMMITTED禁用间隙锁、幻读风险高；SELECT ... FOR UPDATE会锁范围而非单行。
MySQL 默认隔离级别是 REPEATABLE READ，但不是所有场景都安全
MySQL 8.0+ 默认使用 REPEATABLE READ，它通过 MVCC + 间隙锁（Gap Lock）防止幻读，但仅对「当前读」（如 SELECT ... FOR UPDATE、UPDATE、DELETE）生效；普通 SELECT 是快照读，不加锁，也不受间隙锁影响。这意味着：两个事务并发执行普通查询时，可能看到彼此未提交的修改（取决于是否已开启事务及是否触发一致性视图），但不会因插入新行而产生幻读——前提是用了当前读。
- 如果业务依赖「可重复读」语义做判断（比如先查再 insert 防重），必须显式用
SELECT ... FOR UPDATE或SELECT ... LOCK IN SHARE MODE，否则快照读会绕过锁机制 -
READ COMMITTED下间隙锁被禁用（除外键检查和唯一索引冲突），幻读风险上升，但非阻塞程度更高，适合高并发只读+短更新场景 - MySQL 不支持真正的
READ UNCOMMITTED—— 它会忽略该设置，实际降级为READ COMMITTED
SELECT ... FOR UPDATE 在 REPEATABLE READ 下会锁住范围，不只是命中行
这是最容易踩坑的地方：即使 WHERE 条件走索引，SELECT ... FOR UPDATE 也会基于聚簇索引加间隙锁，锁定「满足条件的记录区间」，而非单条记录。例如表 t(id PK, name) 中有 (1,'a'), (5,'e'), (10,'j')，执行 SELECT * FROM t WHERE id > 3 AND id ，会锁住 (1,5)、(5,10) 两个间隙，以及记录 5 —— 新插入 id=4 或 id=7 都会被阻塞。
- 若只想锁具体行，确保 WHERE 精确匹配唯一索引（如
WHERE id = 5），且该值存在；否则仍可能升级为范围锁 - 没有索引的 WHERE 条件会导致全表扫描+全表行锁，等价于表级锁，务必避免
- 在
READ COMMITTED下，同样语句只锁命中的行，不锁间隙，但代价是可能出现幻读
并发更新同一行时，UPDATE 的加锁行为取决于 WHERE 和索引
MySQL 的 UPDATE 默认是当前读，一定加锁。但锁类型（记录锁 / 间隙锁 / 临键锁）由执行计划决定：
- WHERE 匹配唯一索引且值存在 → 加
Record Lock（仅锁该行） - WHERE 匹配唯一索引但值不存在 → 加
Gap Lock（锁前后间隙） - WHERE 匹配非唯一索引或范围条件 → 加
Next-Key Lock（记录锁 + 间隙锁组合） - WHERE 不走索引 → 全表扫描，每行加记录锁，同时可能锁间隙，性能灾难
典型错误是写 UPDATE user SET status=1 WHERE name='xxx' 却没给 name 建索引，导致并发更新时大量锁等待甚至死锁。
启科网络商城系统由启科网络技术开发团队完全自主开发，使用国内最流行高效的PHP程序语言，并用小巧的MySql作为数据库服务器，并且使用Smarty引擎来分离网站程序与前端设计代码，让建立的网站可以自由制作个性化的页面。 系统使用标签作为数据调用格式，网站前台开发人员只要简单学习系统标签功能和使用方法，将标签设置在制作的HTML模板中进行对网站数据、内容、信息等的调用，即可建设出美观、个性的网站。
死锁检测开销不可忽视，innodb_deadlock_detect 关闭后需靠超时兜底
MySQL 默认开启死锁检测（innodb_deadlock_detect=ON），会在每次加锁时做环路检测。高并发短事务下，这个检测本身会成为瓶颈。有些场景（如热点账户余额更新）会考虑关掉它，改用 innodb_lock_wait_timeout（默认 50 秒）兜底。
- 关闭后，事务只能靠超时退出，无法及时感知死锁，应用层必须处理
Lock wait timeout exceeded错误并重试 - 更稳妥的做法是：控制事务粒度（越小越好）、按固定顺序访问多行（如总是先更新 user 再更新 order）、避免在事务中做 RPC 或 sleep
- 用
SHOW ENGINE INNODB STATUS可查最近死锁详情，关键看*** (1) WAITING FOR THIS LOCK TO BE GRANTED:和*** (2) HOLDS THE LOCK(S):两段
隔离级别不是银弹，锁行为才是并发问题的真正源头。调低级别不一定提升性能，反而可能引入业务逻辑漏洞；盲目加锁又容易拖垮吞吐。得结合具体 SQL 的执行计划、索引结构、数据分布来判断。
