mysql存储过程不能直接用limit+offset分页，因游标不支持动态偏移，fetch只能顺序取行；应改用变量计数控制每批数量，并通过where条件实现断点续传，且应用层游标更高效稳定。
MySQL存储过程里为什么不能直接用 LIMIT + OFFSET 做分页拉取
因为游标（CURSOR）本身不支持动态偏移，FETCH 只能顺序取下一行，没法跳到第 N 行。你写 DECLARE cur1 CURSOR FOR SELECT ... LIMIT 100 OFFSET 500 看似可行，但 OFFSET 是在查询执行时就固化了结果集快照——后续 FETCH 仍是从头开始逐行读，和“分批拉取”想要的「每次取一个固定窗口」逻辑不一致。
真正要实现“基于游标的分页批量拉取”，核心是：用游标顺序遍历，靠变量计数 + 批量退出控制每轮取多少条，而不是依赖 SQL 层的 LIMIT/OFFSET。
怎么用游标 + 循环变量控制每批拉取数量
关键在于用两个整型变量：v_counter 记当前已取行数，v_batch_size 定义单批上限；再配合 NOT FOUND 处理游标结束。每次 FETCH 后立刻检查是否达到批次上限或游标耗尽。
-
v_batch_size必须在循环外初始化，否则每次循环重置为 0 -
FETCH后必须紧跟IF done THEN LEAVE read_loop; END IF;，否则可能多取一行导致越界 - 不要在
FETCH前做SET v_counter = v_counter + 1，否则首行计数会错位
DECLARE v_id INT; DECLARE v_name VARCHAR(50); DECLARE v_counter INT DEFAULT 0; DECLARE v_batch_size INT DEFAULT 100; DECLARE done INT DEFAULT FALSE; DECLARE cur1 CURSOR FOR SELECT id, name FROM users ORDER BY id; DECLARE CONTINUE HANDLER FOR NOT FOUND SET done = TRUE; <p>OPEN cur1; read_loop: LOOP FETCH cur1 INTO v_id, v_name; IF done OR v_counter >= v_batch_size THEN LEAVE read_loop; END IF;</p><p>-- 这里处理单行数据，比如 INSERT INTO tmp_table 或 CALL another_proc(v_id) INSERT INTO batch_log VALUES (v_id, v_name, NOW());</p><p>SET v_counter = v_counter + 1; END LOOP; CLOSE cur1;</p>
如何让游标分页支持“从指定位置继续”（断点续传）
纯游标无法跳转，所以得把“上一批最后的主键值”作为参数传入，改写游标查询条件。例如按 id 升序分页，第二批就该从 WHERE id > last_seen_id 开始。
- 游标声明必须带
WHERE条件，且该条件字段要有索引，否则性能崩塌 - 调用时传入的
last_id参数建议设为INOUT，方便在过程末尾更新为本次最后取到的id - 如果表无合适单调主键，可用
(created_at, id)组合，但游标 SQL 中ORDER BY和WHERE必须严格匹配索引顺序
CREATE PROCEDURE fetch_users_batch(
IN last_id INT,
INOUT next_last_id INT,
IN batch_size INT
)
BEGIN
DECLARE v_id INT;
DECLARE v_name VARCHAR(50);
DECLARE done INT DEFAULT FALSE;
DECLARE cur1 CURSOR FOR
SELECT id, name FROM users
WHERE id > last_id
ORDER BY id
LIMIT batch_size;
DECLARE CONTINUE HANDLER FOR NOT FOUND SET done = TRUE;
<p>OPEN cur1;
read_loop: LOOP
FETCH cur1 INTO v_id, v_name;
IF done THEN LEAVE read_loop; END IF;
-- 处理 v_id, v_name ...
SET next_last_id = v_id; -- 记住最后一条
END LOOP;
CLOSE cur1;
END</p>
为什么实际项目中更推荐用应用层游标而非存储过程游标
MySQL 游标是**全表扫描式单向只读**，不支持反向、随机访问，且在事务中持有锁时间长。当你要拉取千万级数据并分批处理时，存储过程游标容易卡住其他写操作，还无法利用连接池并发拉取。
- 存储过程游标每打开一次，就锁定整个结果集对应的数据页（取决于隔离级别），而应用层用
SELECT ... WHERE id > ? ORDER BY id LIMIT ?可以精确控制锁范围 - Java/Python 客户端可开多个连接并行拉不同区间，MySQL 存储过程只能单线程串行
- 错误恢复难：存储过程中某批出错，
next_last_id可能没更新成功，下次调用就漏数据；应用层可以显式记录 checkpoint 到独立表
真要用存储过程做批量拉取，只适合小规模、低频、强一致性要求的场景，比如定时同步配置表。大规模数据迁移，老老实实用应用层分页 SQL + 幂等处理更稳。
