存储过程批量更新卡死服务的根源在于未合理控制事务边界和索引失效。必须在循环内每批后显式commit，避免长事务锁表；同时确保where条件走索引，杜绝隐式转换与函数包裹导致的全表扫描。
存储过程里批量更新卡死服务，不是因为用了存储过程，而是它默认把整批操作包在一个长事务里——锁不释放，别的查询就只能干等。
存储过程里没显式 COMMIT 就等于没事务边界
MySQL 存储过程默认不自动提交，哪怕你写了 UPDATE 一百次，只要没 COMMIT，整个过程就卡在同一个事务里。InnoDB 的锁会一直持有到事务结束，而存储过程往往一口气跑完，锁住几万行、几分钟，其他连接全堵在 Waiting for table metadata lock 或直接超时。
- 必须在循环体内每批后加
COMMIT，不能只在存储过程末尾写一次 - 避免依赖
AUTOCOMMIT=1：存储过程里该值可能被覆盖，务必显式设SET autocommit = 0后再手动控制 - 别用
START TRANSACTION包整个过程——那是自找死锁；应该每批单独BEGIN/COMMIT
WHERE 条件没走索引，存储过程也救不了你
哪怕你在存储过程里分了 100 批，只要每批的 WHERE 没命中索引，MySQL 还是会全表扫描、全表加锁。这时候分批只是把“锁表”拆成“锁表 × 100”，反而更耗资源。
- 执行前用
EXPLAIN验证每条UPDATE的type不是ALL，rows接近你要更新的实际行数 - 警惕隐式转换：
WHERE status = 1（但status是VARCHAR）会失效索引 - 函数包裹必废索引：
WHERE DATE(create_time) = '2026-08-10'→ 改成create_time >= '2026-08-10' AND create_time
用主键游标切分，别信 LIMIT + OFFSET
存储过程里写 UPDATE ... LIMIT 1000 看似简单，但 MySQL 仍可能重复扫描前面已处理过的行，尤其当数据被并发修改时，容易漏更新或重复更新。更糟的是，LIMIT 不影响锁范围——没索引时照样锁全表。
- 正确做法：先查一批
id，比如SELECT id FROM t WHERE status = 0 ORDER BY id LIMIT 1000，再用UPDATE t SET ... WHERE id IN (...) - 更稳妥：用
WHERE id > @last_max_id AND id ，下一批起始值取上一批的 <code>MAX(id) - 单批建议 100–500 行；若字段大或涉及 JOIN，降到 ≤100 更稳
多表更新顺序不统一，死锁就是时间问题
存储过程常要更新 order、order_item、user 多张表。如果两个并行调用分别按不同顺序加锁（比如一个先 order 再 order_item，另一个反过来），死锁必然发生——不是“可能”，是“一定”。
- 所有存储过程必须约定唯一加锁顺序，例如按表名字母序：
order_item→order→user - 禁止根据业务类型动态拼 SQL 表顺序，比如 refund 流程先改 user，正常流程先改 order
- 每张表的更新都必须基于主键或唯一索引，避免
SELECT FOR UPDATE意外升级为间隙锁
真正难的不是写循环，而是让每次 UPDATE 都精准命中、快速提交、锁不扩散。很多存储过程跑着跑着就卡住，问题不在逻辑，而在每一行 SQL 背后的执行计划和锁行为被忽略了。
