SQL批量更新需分批执行、缩小事务粒度、避免全表扫描、合理使用索引；按主键或索引字段切片，每次更新2000–5000行，确保WHERE条件走索引，防止锁升级与性能恶化。
SQL批量更新不加控制容易引发锁表、慢查询甚至服务阻塞。核心思路是：分批执行、缩小事务粒度、避免全表扫描、合理使用索引。
分批次更新，降低单次事务压力
一次性更新百万级数据会持有行锁/页锁过久，导致其他查询或更新被阻塞。应按主键或有索引的字段切片，每次只更新几千条。
- MySQL示例（按id分页）：
UPDATE user SET status = 1 WHERE id BETWEEN 10001 AND 15000 AND status = 0; - 用循环或脚本控制批次，例如每次取5000条，检查影响行数是否为0来终止
- 批次大小建议2000–5000，具体根据单行数据大小和服务器负载调整
确保WHERE条件走索引，避免全表扫描锁
如果UPDATE的WHERE子句无法命中索引，数据库可能升级为表级锁（尤其MyISAM）或大量行锁（InnoDB），大幅延长锁持有时间。
- 执行EXPLAIN UPDATE ...（部分版本不支持，可改写为SELECT验证）确认key列非NULL
- 常见陷阱：对字段做函数操作，如WHERE DATE(create_time) = '2024-01-01' → 改为WHERE create_time >= '2024-01-01' AND create_time
- 联合索引要注意最左匹配，WHERE中缺失前导列会导致索引失效
用主键IN替代模糊条件，提升定位效率
当需按业务逻辑筛选（如一批订单号），优先查出ID列表再更新，比在UPDATE里写复杂JOIN或子查询更可控、更易索引。
- 先查ID：
SELECT id FROM order WHERE shop_id IN (101,102) AND status = 'unpaid' LIMIT 5000; - 再更新：
UPDATE order SET status = 'paid' WHERE id IN (1001,1002,...,5000); - 注意IN列表长度限制（MySQL默认max_allowed_packet影响），超长时拆成多个语句
配合低峰期+事务控制，减少业务影响
即使优化了SQL，也建议避开流量高峰，并显式控制事务边界，防止意外长事务。
- 在应用层用BEGIN / COMMIT包裹每批更新，避免自动提交模式下隐式长事务
- 设置超时：SET innodb_lock_wait_timeout = 10; 防止死等锁
- 监控锁等待：SELECT * FROM information_schema.INNODB_TRX; 和 INNODB_LOCK_WAITS
