SQL锁机制是数据库协调并发访问的“交通管制员”，通过行级X锁、间隙锁、意向锁等防止数据错乱，核心在于明确“谁在什么时候为什么锁什么、锁多久、影响谁”。
SQL锁机制本质是数据库用来协调并发访问的“交通管制员”——当多个事务同时想读或改同一行、同一张表时，它通过加锁防止数据错乱。理解关键不在背类型，而在搞清“谁在什么时候为什么锁什么、锁多久、影响谁”。下面用高频真实场景带你直观掌握。
一、更新商品库存：行级写锁（UPDATE自带X锁）
电商秒杀最典型：用户A和B几乎同时下单同一款手机，库存只剩1台。
- 事务A执行：UPDATE products SET stock = stock - 1 WHERE id = 1001; → 数据库立即对id=1001这行加排他锁（X锁），其他事务无法再对该行做UPDATE/DELETE，连SELECT ... FOR UPDATE也会被阻塞
- 事务B紧跟着执行同样UPDATE → 被挂起，等待A提交或回滚
- A提交后，B才能继续执行（此时stock可能已为0，B需自行判断业务逻辑是否允许）
✅ 关键点：UPDATE默认加行级X锁，不是锁整张表；锁在事务结束（COMMIT/ROLLBACK）时才释放；没索引条件（如WHERE name='iPhone'）可能导致升级为表锁，务必加索引！
二、生成订单号：间隙锁防幻读（InnoDB特有）
订单号要求连续递增（如ORD20240001、ORD20240002），用SELECT MAX(id) + 1方式生成，但并发下会重复。
- 事务A查：SELECT MAX(order_no) FROM orders WHERE order_no LIKE 'ORD2024%'; → 返回ORD20240005
- 事务B同一时刻也查到ORD20240005
- A插入ORD20240006，B也插入ORD20240006 → 冲突！
? InnoDB在可重复读（RR）隔离级别下，这个SELECT会触发间隙锁（Gap Lock），锁住 ORD20240005 和下一个可能值之间的空隙（比如 ORD20240005 到 ORD20249999 的范围），让B的SELECT被阻塞，直到A插入并提交。这就是为什么RR能解决幻读——靠的是间隙锁+临键锁（Next-Key Lock），不是MVCC单独完成的。
三、报表统计卡死：长事务+全表扫描引发锁升级
运营同学跑一个未加LIMIT的慢查询：SELECT * FROM user_logs WHERE create_time > '2024-01-01';，表无create_time索引。
- 查询全表扫描，InnoDB可能对扫描过的每行都加意向共享锁（IS），持续数分钟
- 此时客服系统要UPDATE某用户状态：UPDATE users SET status = 'locked' WHERE id = 12345; → 若user_logs和users有关联（如触发器、外键），或该用户日志正在被扫描，UPDATE可能被阻塞
- 更糟的是，某些情况下（尤其内存紧张），行锁可能升级为表锁，整个users表写操作全卡住
✅ 避坑：报表查询加索引、加LIMIT、设查询超时；避免在事务里执行长查询；监控information_schema.INNODB_TRX看长时间运行事务。
四、只读查询也抢锁？SELECT ... FOR UPDATE vs LOCK IN SHARE MODE
不是所有SELECT都无害。两种显式加锁的SELECT会真正参与锁竞争：
- SELECT ... FOR UPDATE; → 加X锁，其他事务不能读（带FOR UPDATE/SHARE）也不能写，常用于“读-改-写”闭环，如先查余额再扣款
- SELECT ... LOCK IN SHARE MODE; → 加S锁，其他事务可读，但不能加X锁（即不能UPDATE/DELETE），适合多事务协同读取同一数据做校验
- 普通SELECT（无LOCK）在RR级别走MVCC快照读，不加锁，不阻塞别人——这才是高并发下的推荐姿势
⚠️ 注意：即使加了FOR UPDATE，如果WHERE条件没走索引，还是会锁全表！
基本上就这些。锁不是越少越好，也不是越多越安全；核心是结合业务场景，用最小粒度锁（优先行锁）、最短持有时间（事务别拖太久）、最准匹配条件（必须有索引）。理解了这几个场景，再去看死锁日志、SHOW ENGINE INNODB STATUS，就不再发怵了。
