存储过程UPDATE用WHERE仍锁整张表，是因未走索引或索引失效导致优化器全表扫描并升级为表级锁；应通过EXPLAIN确认执行计划type为ref/range、避免函数操作、遵循最左前缀原则，并及时更新统计信息。
存储过程里 UPDATE 用 WHERE 但还是锁整张表？
不是语句写错了，是没走索引或索引失效导致 MySQL/SQL Server 自动升级为表级锁。比如 WHERE status = 'pending' 字段没建索引，或者用了函数包装（WHERE DATE(created_at) = '2024-01-01'），优化器无法使用索引，就只能扫全表——锁也就跟着扩大。
实操建议：
- 用
EXPLAIN检查执行计划，确认type是ref或range，不是ALL - 避免在
WHERE条件中对字段做计算、类型转换、函数调用 - 复合索引要注意最左前缀，比如索引是
(user_id, status)，但查询只用status = ?，索引大概率失效 - SQL Server 要留意统计信息是否过期，过旧会导致错误估算行数，触发锁升级（
sp_updatestats可临时缓解）
SELECT ... FOR UPDATE 在存储过程中怎么不阻塞其他事务？
它默认就会阻塞——但阻塞范围取决于你锁定的行是否真被命中，以及隔离级别。常见问题是：明明只查一条记录，却锁住几十行，甚至整个索引区间，原因往往是“间隙锁”（Gap Lock）在起作用。
实操建议：
- MySQL InnoDB 下，
READ-COMMITTED隔离级别可禁用间隙锁（但要承担幻读风险），比默认的REPEATABLE-READ更轻量 - 确保
FOR UPDATE的条件能精确命中索引键值，例如用主键WHERE id = 123，而不是非唯一索引WHERE order_no = 'ABC'（可能锁多个相同值的行+间隙） - SQL Server 中改用
UPDLOCK, ROWLOCK提示，但必须配合索引查找，否则提示会被忽略 - 别在
FOR UPDATE后面加ORDER BY或LIMIT不明确的逻辑，可能导致锁范围不可控
存储过程里多个 UPDATE 串行执行，锁等待时间越来越长？
本质是事务生命周期太长 + 锁持有时间拉得过久。一个存储过程里先 UPDATE A 表，再查 B 表，再 UPDATE C 表，中间还夹着业务逻辑计算——A 表的行锁会一直持有着，直到整个存储过程 COMMIT 或 ROLLBACK。
实操建议：
- 把非数据库操作（如字符串拼接、循环计算）尽量提到事务外，或拆成多个短事务
- 如果必须多步更新，考虑用
SELECT ... INTO或临时表提前捞出关键数据，减少锁期间的依赖 - PostgreSQL 用户注意：
UPDATE默认不锁未修改的列，但若触发了BEFORE UPDATE触发器且里面做了SELECT FOR UPDATE，锁就悄悄扩散了 - SQL Server 存储过程中慎用
@@TRANCOUNT判断嵌套事务，隐式事务开启（SET IMPLICIT_TRANSACTIONS ON）容易让锁意外延长
并发调用同一存储过程时，不同参数却互相锁等？
这不是锁错对象，而是你锁的“粒度单位”和“参数分布”不匹配。比如按 tenant_id 分库分表，但存储过程里用的是全局 id 更新，或所有调用都走同一个缓存 key 导致排队执行——表面是锁问题，实则是设计耦合。
实操建议：
- 检查存储过程入参是否真能映射到独立数据分区，比如
UPDATE orders SET status = ? WHERE tenant_id = @tid AND id = @oid，必须确保@tid索引有效且高基数 - 避免在存储过程中用
SELECT MAX(id) + 1类逻辑生成主键，这本质上是表级互斥操作 - MySQL 8.0+ 可考虑用
SKIP LOCKED（如SELECT ... FOR UPDATE SKIP LOCKED LIMIT 1）来避免抢同一行，但仅适用于任务队列类场景 - SQL Server 的
sp_getapplock是应用层锁，不是行锁，别误以为它能替代索引优化——它只是把竞争从数据库层搬到应用层而已
锁竞争从来不是单点问题，它暴露的是索引设计、事务边界、参数语义、甚至分片策略的断层。调优时最容易忽略的，是把“锁住了哪几行”和“为什么偏偏是这几行”画上等号——而真相往往藏在执行计划的 key_len 和 rows_examined 里。
