存储过程本身不拖慢UPDATE，真正原因是默认长事务导致锁表、日志膨胀和资源占用；应分批提交、优化索引、避免函数破坏索引、慎用游标，核心在于事务控制与执行计划优化。
为什么存储过程里的UPDATE容易变慢
不是存储过程本身拖慢了UPDATE，而是它默认把所有逻辑塞进一个长事务里。你写个循环更新10万行，只要没显式COMMIT，InnoDB就一直拿着锁、攒着redo log、占着undo空间——结果不是SQL慢，是锁住了其他业务，还可能触发innodb_lock_wait_timeout或Lock wait timeout exceeded错误。
- 用
EXPLAIN FORMAT=TRADITIONAL检查核心UPDATE语句，确认type是ref或range，不是ALL - 别在
WHERE或JOIN条件里用函数，比如UPPER(name)或DATE(created_at)，这会让索引失效 - 复合条件优先建联合索引，顺序按等值字段在前、范围字段在后，例如
WHERE status = ? AND updated_at > ?，索引应为(status, updated_at)
分批提交必须手动控制，不能靠循环自动拆分
存储过程不会帮你自动切批次。哪怕你写了FOR i IN 1..10000，只要没在循环体内COMMIT，它还是一个事务。正确做法是用主键范围+固定大小分片，每次更新后立刻提交：
DECLARE batch_size INT DEFAULT 500; DECLARE offset_val BIGINT; SELECT MIN(id) INTO offset_val FROM orders WHERE status = 'pending'; <p>WHILE offset_val IS NOT NULL DO UPDATE orders SET status = 'processing' WHERE id >= offset_val AND id < offset_val + batch_size AND status = 'pending';</p><p>IF ROW_COUNT() = 0 THEN LEAVE; END IF;</p><p>COMMIT; -- 关键：释放锁，清空日志缓冲 SELECT MIN(id) INTO offset_val FROM orders WHERE id >= offset_val + batch_size AND status = 'pending'; END WHILE;
- 别用
LIMIT做分页切分，MySQL不允许UPDATE ... LIMIT配合JOIN，且LIMIT offset, n在并发写入下会漏数据或重复 -
offset_val必须动态查，不能硬写0或递增计数，否则跳过已删除/插入的ID - 每批大小建议500–5000行，视单行数据体积和服务器
innodb_log_file_size调整
CASE WHEN vs 临时表JOIN：怎么选
当你要按ID列表给每行设不同值（比如商品A改价19.9、B改29.9），CASE WHEN简洁但有长度限制；当要关联多张表或数据量超2000行，临时表更稳：
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
-
CASE WHEN适合≤1000行、目标值可枚举的场景，SQL示例：UPDATE products SET price = CASE id WHEN 101 THEN 19.9 WHEN 102 THEN 29.9 ELSE price END WHERE id IN (101,102) - 临时表适合大批量或需复用中间结果的场景，先
CREATE TEMPORARY TABLE temp_update (id INT PRIMARY KEY, new_price DECIMAL(10,2))，再INSERT INTO temp_update VALUES (101,19.9),(102,29.9)，最后UPDATE products p JOIN temp_update t ON p.id = t.id SET p.price = t.new_price - 临时表自动随会话销毁，无需
DROP，但注意不要重名，避免Table 'temp_update' already exists
游标不是万能解药，慎用LIMIT i,1分页取数
用LIMIT i,1在循环中逐条取ID，是线上最常踩的坑之一。源表若发生删改，i递增后可能查不到新行，或重复取同一行，导致死循环或漏更新。
- 真要用游标，必须带
ORDER BY id确保顺序稳定，并用DECLARE CONTINUE HANDLER FOR NOT FOUND捕获结束，而不是靠预估总行数硬算 - 游标本身不解决性能问题，只是让“逐条处理”更可靠；性能瓶颈仍在网络往返和事务开销，所以仍需配合分批
COMMIT - 如果更新逻辑涉及复杂计算（如调用函数、查多张表），优先考虑把计算结果提前载入临时表，再用
JOIN更新，避免在循环内反复执行子查询
真正卡住批量UPDATE的，往往不是语法写得对不对，而是事务边界划在哪、锁什么时候放、索引有没有被用上。这些细节藏在EXPLAIN输出里，也藏在SHOW PROCESSLIST的状态中，而不是存储过程的括号嵌套深度里。
