索引 idx_outer_loan_id 生效需 where 首先包含 outer_loan_id，且 cur_term 应加入索引；避免隐式转换、更新大批量时分批处理，并检查统计信息与执行计划。
WHERE条件没命中索引最左前缀
联合索引 idx_outer_loan_id (outer_loan_id, org_id, product_id) 要生效，WHERE 必须包含 outer_loan_id（最左列）。你当前的 UPDATE 语句 WHERE 条件是：org_id='XXX' AND product_id='XXX' AND outer_loan_id='XXX' AND cur_term='6'——虽然含 outer_loan_id，但 SQL Server 优化器可能因谓词顺序、统计信息陈旧或隐式转换，未能识别其可用性。
实操建议：
- 显式按索引定义顺序写 WHERE，例如先写
outer_loan_id = 'XXX'，再写org_id和product_id - 用
DBCC SHOW_STATISTICS('partner_common_repay_plan', 'idx_outer_loan_id')检查统计信息是否过期；若rows_sampled ，执行 <code>UPDATE STATISTICS partner_common_repay_plan idx_outer_loan_id WITH FULLSCAN - 确认
outer_loan_id列在 WHERE 中的值类型与表定义一致（比如 VARCHAR 字段不能传数字字面量，否则触发隐式转换）
cur_term 列不在索引中导致回表或索引失效
你的索引 idx_outer_loan_id 不含 cur_term，而 WHERE 中又用了它。SQL Server 无法仅靠该索引完成过滤，可能退化为索引扫描 + KEY LOOKUP，甚至直接放弃索引走全表扫描——尤其当 cur_term 选择性差（如大量值为 6）时，优化器会认为全表扫描更便宜。
实操建议：
- 扩展索引覆盖：新建索引
idx_covering (outer_loan_id, org_id, product_id) INCLUDE (cur_term)，或更优地，把cur_term加入键列形成(outer_loan_id, org_id, product_id, cur_term) - 避免在 WHERE 中对
cur_term使用函数或表达式（如CAST(cur_term AS VARCHAR) = '6'），这会直接让索引失效 - 用
SET STATISTICS XML ON查看实际执行计划，确认是否出现 “Index Scan” 或 “Table Scan”，而非 “Index Seek”
数据类型不匹配引发隐式转换
如果 org_id 或 product_id 是 VARCHAR，但你在 WHERE 中写了 org_id = 123（无引号），SQL Server 会把整列转成 INT 做比较，导致索引无法 seek——这是典型的隐式转换陷阱。
常见错误现象：
- 执行计划中出现
CONVERT_IMPLICIT算子 - 同样语句，加引号后变快，不加就慢几十倍
-
sys.dm_exec_query_stats中该语句的logical_reads异常高（比如数百万）
实操建议：
- 统一用字符串字面量：写成
org_id = '123'，而不是org_id = 123 - 用
SELECT system_type_name FROM sys.dm_exec_describe_first_result_set(N'your UPDATE...', NULL, 0)核对参数推断类型 - 在开发阶段开启
SET ANSI_WARNINGS ON，提前暴露类型不一致警告
UPDATE 涉及大量行时锁升级触发扫描行为
你日志里看到 25610952 行锁、Lock_time 占比超 90%，说明事务已触发锁升级（从行锁升为表锁）。一旦升级发生，SQL Server 可能直接跳过索引查找逻辑，改用全表扫描来定位待更新行——因为“反正都要锁全表了”。这不是优化器选错计划，而是锁机制倒逼行为。
关键点：
- 锁升级阈值默认是 5000 行，但受内存压力、并发事务影响，实际可能更低
- 即使 WHERE 条件精准，只要预估要更新的行数超过阈值，就可能走 Table Scan
- 这种扫描不会出现在 EXPLAIN/执行计划里，但会在
sys.dm_tran_locks和慢日志中暴露
实操建议：
- 分批更新：用
TOP (5000)+ 循环，配合WHERE ... AND id > @last_id控制范围 - 检查是否有未提交事务长期持有表级锁（
SELECT * FROM sys.dm_tran_locks WHERE resource_type = 'OBJECT'） - 临时降低锁升级阈值测试：用
ALTER TABLE partner_common_repay_plan SET (LOCK_ESCALATION = DISABLE)（仅调试，勿上线）
真正卡住的往往不是“有没有索引”，而是 WHERE 条件和索引结构之间那几处细微错位——尤其是 cur_term 这种高频过滤字段被漏掉，或者字符串比较时少打了一对单引号。
