应使用主键游标分批更新：每次SELECT ... WHERE id > @last_id ORDER BY id LIMIT N，更新后SELECT @last_id := MAX(id)，并确保WHERE字段有联合索引，每批后显式COMMIT。
MySQL存储过程里怎么分批更新才不卡死
直接用UPDATE ... LIMIT在存储过程中分页是危险的——它不保证按主键顺序执行，可能跳行或重复，尤其在并发写入时。真正安全的做法是用带ORDER BY id的TOP逻辑模拟游标推进。
- 必须有明确排序：每次
SELECT ... WHERE id > @last_id ORDER BY id LIMIT 5000，否则LIMIT行为不可预测 - WHERE条件字段（如
status = 'pending'）要建联合索引，否则每次都是全表扫描 - 每批更新后，用
SELECT @last_id := MAX(id) FROM t WHERE id 刷新边界，别依赖<code>@@ROWCOUNT推算 - 加
IF @@ROWCOUNT = 0 THEN LEAVE loop_label; END IF;防止空结果死循环 - 每批结束后显式
COMMIT，不能依赖隐式提交；若用AUTOCOMMIT = 0，更要确保没漏掉
为什么SET @var := @var + 1在循环里会漏数据
MySQL变量在子查询中复用时，顺序不保，尤其当ORDER BY缺失或被优化器忽略，@row_index := @row_index + 1可能在不同批次间错位，导致某批跳过几百行。
- 每次进入循环前必须重置：
SET @row_index := 0;，否则第二次执行会从上次结束值继续 - 子查询内
@row_index赋值必须配合ORDER BY id，且该字段要有索引，否则优化器可能改写执行计划 - 并发场景下，多个存储过程实例共享同名变量，极易互相污染——建议改用临时表存中间状态，或由应用层控制分片
- 更稳妥替代方案：用
INSERT INTO tmp_batch SELECT id FROM t WHERE ... ORDER BY id LIMIT 5000先取ID集合，再基于该集合更新，避免变量副作用
innodb_log_file_size调大真能缓解日志暴涨吗
不能。调大innodb_log_file_size只影响checkpoint频率和崩溃恢复时间，对事务提交卡顿、日志写满报错（如ERROR 1197）几乎无改善，反而可能让问题更隐蔽。
- 真正瓶颈常在
innodb_log_buffer_size太小（默认16MB），高并发小事务反复触发隐式刷盘，此时增大buffer比动log file更有效 -
innodb_log_file_size修改必须停库：删掉ib_logfile*后重启，否则启动失败；且新值需满足innodb_log_file_size >= innodb_log_buffer_size * 4才合理 - 如果
SHOW STATUS LIKE 'Innodb_log_waits'> 0，优先检查innodb_log_buffer_size和事务拆分，而不是log file - 盲目调大还可能延长崩溃恢复时间，线上环境慎改
杀长事务前不看trx_state等于埋雷
查INFORMATION_SCHEMA.INNODB_TRX时只盯trx_started时长是错的，很多“长事务”其实早已空闲但没提交，真正要砍的是trx_state = 'RUNNING'且trx_query IS NULL的那批。
-
trx_state = 'RUNNING'且trx_query IS NULL：大概率是应用漏了COMMIT或连接池未close，可安全KILL -
trx_state = 'LOCK WAIT'：说明它被别的事务堵住，先查INNODB_LOCK_WAITS找出blocking_trx_id，干上游 -
trx_state = 'ROLLING BACK'：千万别KILL，此时强制中断会让回滚转为异步，IO翻倍、耗时拉长数倍 - 若
History list length > 10000，批量KILL必须加SLEEP(0.2)间隔，否则purge线程可能被IO压垮
分批逻辑本身不复杂，难的是每一步都得踩准数据库的状态反馈。比如@@ROWCOUNT是否真代表本次更新行数，trx_state是否反映真实阻塞点，这些细节一旦忽略，表面跑通的存储过程，可能正在 silently 撑爆undo或binlog。
