SQL锁范围由执行计划决定，取决于索引、隔离级别、语句写法等；无索引时WHERE条件可能导致全表锁，有合适索引则通常仅锁匹配行；RC下仅锁命中行，RR下加间隙锁扩大范围；批量操作需分批限流，FOR UPDATE须走索引避免锁表。
SQL数据库的锁范围控制，核心在于平衡数据一致性与并发性能。锁范围过大（如表级锁）会导致阻塞严重；过小（如行级锁）可能引发锁升级失败或死锁。实际效果取决于隔离级别、索引设计、语句写法和事务长度。
锁范围由执行计划决定，不是由SQL字面决定
即使写的是 UPDATE users SET status = 1 WHERE id = 100，若 id 列没有索引，优化器可能走全表扫描，最终对整张表加锁（或大量页锁）。反之，有合适索引时通常只锁定匹配的单行（InnoDB 行锁）。
- 用
EXPLAIN或执行计划查看是否命中索引 - 避免在
WHERE条件中对字段使用函数或隐式转换（如WHERE YEAR(create_time) = 2024），否则索引失效，锁范围扩大 - 联合索引要注意最左前缀原则，否则可能退化为范围扫描甚至全扫
不同隔离级别影响锁的类型与持续时间
读已提交（RC）下，普通 SELECT 不加锁，UPDATE/DELETE 只锁命中的行，且仅在事务提交前持有；可重复读（RR）下，InnoDB 会加间隙锁（Gap Lock）防止幻读，锁住索引区间，范围可能远超实际更新行数。
- 高并发写场景可考虑降级到 RC（需业务接受“不可重复读”）以减少间隙锁开销
- 若必须用 RR，尽量让
WHERE条件走唯一索引（如主键或唯一键），此时 InnoDB 通常只加记录锁（Record Lock），不加间隙锁 -
SELECT ... FOR UPDATE和SELECT ... LOCK IN SHARE MODE在 RR 下也会触发间隙锁，需谨慎使用
批量操作天然扩大锁范围，需分批+限流
一次更新十万行，不仅锁住所有目标行，还可能触发锁升级（如 SQL Server）或导致事务日志暴涨、回滚段压力大。InnoDB 虽不升级锁，但长事务会让锁长期持有，阻塞其他会话。
- 用
LIMIT分批次处理（如每次 500 行），配合WHERE id > last_id ORDER BY id LIMIT 500避免重复 - 每批执行后短暂休眠（如 10–100ms），缓解系统压力
- 避免在事务中嵌套循环大批量更新；优先用单条
INSERT ... ON DUPLICATE KEY UPDATE或MERGE替代
显式锁控制：慎用，但必要时很关键
当默认行为无法满足需求（如防止并发插入重复业务单号），可用 SELECT ... FOR UPDATE 提前锁定资源。但注意它锁定的是查询结果集对应的索引记录——哪怕只是 SELECT id FROM orders WHERE order_no = 'NO123'，也会锁住该 order_no 对应的聚簇索引行。
- 确保
FOR UPDATE的 WHERE 条件走索引，否则可能锁表 - 尽量缩短事务内持有锁的时间：查完立刻更新，不要在锁住后做 HTTP 调用、文件读写等耗时操作
- 多个资源锁定顺序要一致（如按主键升序获取），避免死锁
锁不是越细越好，也不是越少越好。关键是让锁落在最小必要集合上，并尽快释放。理解执行路径、善用索引、控制事务粒度，比背诵锁类型更有效。
