MySQL 存储过程中怎么声明和打开游标
游标只能在存储过程或函数里用，不能在普通 SQL 会话中直接 DECLARE CURSOR。声明前必须先定义好结果集的 SELECT 语句，且该语句不能含变量（除非用 PREPARE 动态拼接，但那是另一套逻辑）。
常见错误是把游标声明放在变量声明之前，或者漏掉 DECLARE CONTINUE HANDLER——一旦取到末尾没处理，过程就直接报错退出。
-
DECLARE游标必须在DECLARE变量之后、BEGIN块主体之前 - 游标名不能和已存在的变量/参数同名，否则 MySQL 会静默忽略游标声明
-
OPEN之后才真正执行查询；如果 SELECT 涉及大表且无索引，OPEN就可能卡住
FETCH 逐行读取时为什么老取不到数据
最常踩的坑：没设 NOT FOUND 处理器，或设了但 handler 体里没改标志位。MySQL 的游标没有“是否还有下一行”的主动判断函数，全靠 SQLSTATE '02000' 或 FOUND_ROWS()（后者不适用于游标）触发 handler。
注意 FETCH 本身不返回布尔值，它只是把当前行字段赋给变量；如果已到结果集末尾，变量值不会变，也不会报错——你得靠 handler 主动捕获并跳出循环。
- 必须用
DECLARE CONTINUE HANDLER FOR NOT FOUND SET done = TRUE;这类结构，done是你自己定义的BOOLEAN或TINYINT变量 -
FETCH后立即检查done，而不是在循环条件里写WHILE NOT done DO——因为第一次FETCH前done是FALSE，但还没取数据 - 别在 handler 里写
LEAVE，它只跳出 handler 作用域，不是跳出外层循环
游标性能差，有没有更轻量的替代方案
游标本质是服务端逐行缓存 + 重复赋值，对上万行结果集，比一次性查出来在应用层遍历还慢。尤其是嵌套游标（一个游标里再开另一个），容易锁表、拖慢事务。
如果不是必须在存储过程内完成全部逻辑（比如要调用其他存储过程、做复杂分支判断），优先考虑把结果集拉到应用层处理。MySQL 本身不支持游标并发读，也不支持跳过某几行（没 FETCH RELATIVE）。
- 单次处理几百行以内，游标可接受；超过 1000 行，建议用
LIMIT+OFFSET分页查，由应用控制循环 - 想避免重复扫描，可在应用层用临时表存中间结果，再对临时表建索引后 JOIN 或子查询
- 某些场景（如更新关联数据）可用
UPDATE ... JOIN或INSERT ... SELECT代替游标循环
关闭游标和异常清理容易被忽略的点
MySQL 不强制要求 CLOSE 游标，存储过程结束时自动释放。但如果你在循环中途 LEAVE 或遇到异常，没显式 CLOSE 就退出，下次同名游标 OPEN 会失败（报 Cursor is already open）。
更隐蔽的问题是：handler 触发后，游标状态不确定，再次 FETCH 可能报 Cursor is not open。所以安全做法是在所有出口路径（正常结束、异常、提前退出）都确保 CLOSE 被执行。
- 用
DECLARE EXIT HANDLER包裹整个逻辑块，在 handler 里加CLOSE - 不要依赖“过程结束自动关”，尤其当游标用于长事务或被多次调用时
-
CLOSE后不能再FETCH，也不能再OPEN同名游标（需重新DECLARE）
游标不是语法糖，它是明确为“必须在服务端逐行决策”设计的机制。只要有一条路能用集合操作绕过去，就别用游标——不是因为它写起来难，而是它把本来可以并行的事，硬生生变成串行，而且出错时很难 debug。
