事务与锁应从并发场景切入，如库存扣减、转账一致性、中间状态读取；MySQL默认REPEATABLE READ依赖MVCC快照读，但当前读、幻读、索引失效导致表锁等易被忽视。
事务与锁不是新手入门第一课，但也不是必须等“完全掌握基础”才能碰——关键看你怎么切入。
事务的 ACID 特性在什么场景下才真正暴露问题？
很多新手学完 START TRANSACTION、COMMIT、ROLLBACK 后以为就懂了事务，结果一写并发代码就出错。真实痛点往往出现在：
- 多个请求同时修改同一行（比如库存扣减），不加事务会超卖
- 转账操作中，A 扣款成功但 B 加款失败，没回滚导致资金丢失
- 读取中间状态（如只读到部分更新的数据），引发业务逻辑误判
建议从一个具体案例入手：用两个终端同时执行 UPDATE product SET stock = stock - 1 WHERE id = 1，观察不加事务 vs 加事务的区别。你会发现，autocommit=1 下每条语句自动提交，根本没机会回滚；而手动开启事务后，才能控制一致性边界。
MySQL 默认隔离级别（REPEATABLE READ）有哪些隐藏行为？
新手常以为“可重复读”就是“每次 SELECT 都看到一样的数据”，其实它靠的是 MVCC + 快照读，但以下情况会打破直觉：
-
SELECT ... FOR UPDATE或SELECT ... LOCK IN SHARE MODE会触发当前读，绕过快照，直接查最新版本并加锁 - 幻读依然存在（比如
SELECT COUNT(*)在事务中两次执行结果不同），只是 InnoDB 用间隙锁（Gap Lock）做了缓解 - 升级为
SERIALIZABLE会强制所有普通SELECT变成加锁读，性能骤降，一般不用
验证方式很简单：
SET autocommit = 0; START TRANSACTION; SELECT * FROM t WHERE id > 5; -- 记住结果 -- 此时另一个会话 INSERT 一条 id=6 的记录并 COMMIT -- 回到第一个会话再 SELECT * FROM t WHERE id > 5；结果不变（快照读） -- 但执行 SELECT * FROM t WHERE id > 5 LOCK IN SHARE MODE；就能看到新行（当前读）
行锁不是对“值”加锁，而是对“索引记录”加锁
这是最容易踩坑的一点。你写 UPDATE user SET name='x' WHERE phone='138...' ，如果 phone 没有索引，InnoDB 会退化为表锁——整张表都被堵住。常见表现：
- 明明只改一行，其他无关 UPDATE 却被阻塞
-
SHOW ENGINE INNODB STATUS\G里看到lock_mode X locks rec but not gap是正常行锁，而lock_mode X locks table就是表锁预警 - 即使有索引，若 WHERE 条件用了函数（如
WHERE UPPER(phone)='138...'）或隐式类型转换，索引也可能失效
检查是否走索引：务必在语句前加 EXPLAIN，确认 type 是 const/ref，且 key 显示实际使用的索引名。
事务和锁本身不难理解，难的是在真实并发路径中预判哪条 SQL 会锁什么、锁多久、会不会死锁。与其先啃理论，不如拿一个带支付/下单的最小 demo，反复制造冲突、观察 INFORMATION_SCHEMA.INNODB_TRX 和锁等待日志——看得见的阻塞，比文档里的定义更有说服力。
