UPDATE慢八成因索引未被实际使用：需确保WHERE条件SARGable、复合索引顺序匹配查询模式、大批量时用主键分批推进，并防范参数嗅探导致执行计划失效。
UPDATE语句在存储过程中跑得慢，八成不是逻辑问题，而是没走索引——哪怕WHERE条件字段明明建了索引，也可能因写法、数据分布或执行计划固化而失效。直接加索引不等于UPDATE就快，关键得让优化器真用上它。
WHERE条件字段必须满足SARGable才能走索引
所谓SARGable（Search ARGument Able），是指WHERE子句中的条件能被优化器转化为索引Seek操作。一旦破坏这个前提，哪怕字段有索引，也只能全表扫描。
-
WHERE status = 'shipped'✅ 可走索引 -
WHERE UPPER(status) = 'SHIPPED'❌ 函数作用于列，索引失效 -
WHERE status LIKE '%shipped'❌ 前导通配符，无法利用B+树有序性 -
WHERE CAST(created AS DATE) = '2024-10-01'❌ 隐式转换+函数，双重失效 - 类型不匹配也危险：
WHERE user_id = '123'（user_id是INT）→ 触发隐式转换，可能丢索引
检查方法：在SSMS或MySQL客户端中对UPDATE语句单独执行EXPLAIN（MySQL）或看实际执行计划（SQL Server），确认“Seek”或“Range Scan”是否出现，而不是“Clustered Index Scan”或“ALL”。
复合索引顺序必须匹配查询模式
单字段索引不够用时，复合索引是提速核心。但顺序错了，等于白建。
- 如果UPDATE是
UPDATE orders SET shipped_at = GETDATE() WHERE status = 'pending' AND tenant_id = 123，索引应为(tenant_id, status)或(status, tenant_id)？答案是：优先等值字段+高选择性字段放前 →(tenant_id, status)更稳（假设tenant_id过滤后只剩几百行，status再筛） - 若还有
AND created > '2024-01-01'这类范围条件，必须放最后：(tenant_id, status, created) - 别漏掉“包含列”：如果UPDATE只改
shipped_at，但WHERE依赖tenant_id + status，那索引本身不需要包含shipped_at；但如果后续要加SELECT或JOIN，考虑把常用查询列加进INCLUDE（SQL Server）或作为索引尾部列（MySQL）
验证方式：用DBCC SHOW_STATISTICS（SQL Server）或SHOW INDEX FROM（MySQL）确认索引键列顺序与密度，避免建了(status, tenant_id)却总用tenant_id = ?单独查。
大批量UPDATE必须配合主键推进式分批+索引覆盖
一次性UPDATE几万行，锁升级、日志暴涨、执行计划退化几乎是必然。此时索引不仅用于定位，更要支撑高效分页推进。
- 禁用
OFFSET / FETCH：SQL Server里UPDATE ... ORDER BY id OFFSET @n ROWS FETCH NEXT 1000 ROWS ONLY会导致每批都重扫前@n行，越往后越慢 - 正确做法是Keyset Pagination：
WHERE status = 'pending' AND id > @last_id ORDER BY id，要求(status, id)有复合索引，且id必须是连续/递增主键 - 每批UPDATE后立即
SELECT @last_id = MAX(id)（而非MIN），避免漏行；并用IF @@ROWCOUNT = 0 BREAK防NULL死循环 - 如果UPDATE涉及JOIN，确保JOIN字段也有对应索引，否则分批后JOIN仍拖垮性能
注意：分批事务的COMMIT必须在每批内完成，不能包在大事务里——否则日志文件撑爆、阻塞其他会话、回滚代价极高。
参数嗅探失效会让索引“忽隐忽现”
同一个存储过程，参数@status = 'pending'时飞快，换@status = 'delivered'就卡住，执行计划却显示走了同一索引？大概率是参数嗅探（Parameter Sniffing）导致计划复用错位。
- 现象本质：SQL Server按首次调用的参数值生成计划并缓存，而该计划对后续参数的选择率预估严重失真
- 临时验证：加
OPTION (RECOMPILE)到UPDATE语句末尾，观察是否变快（仅调试用，勿上线） - 稳妥解法：在存储过程中把入参赋给本地变量再用，例如
DECLARE @local_status VARCHAR(20) = @status; UPDATE ... WHERE status = @local_status→ 优化器放弃嗅探，改用统计信息平均分布估算 - MySQL无原生参数嗅探，但要注意prepared statement缓存行为；若用
PREPARE+EXECUTE，不同参数可能共享执行计划，需结合DEALLOCATE PREPARE控制
真正容易被忽略的是：索引本身没问题，但执行计划被缓存“带偏”了——你盯着索引建了又删、删了又建，问题却始终在计划缓存那一层打转。
