MySQL存储过程游标必须配DECLARE CONTINUE HANDLER FOR NOT FOUND，否则FETCH末尾报1329错误；需在游标DECLARE后、OPEN前声明，done初始化为FALSE；游标SELECT须ORDER BY+索引，更新时用FOR UPDATE确保锁序一致；动态SQL应先写入临时表再游标遍历；大数据量需分批提交避免长事务。
MySQL存储过程游标必须配NOT FOUND HANDLER，否则FETCH到末尾直接报1329错误
游标遍历卡在最后一行、过程突然中断、或者死循环，八成是漏了DECLARE CONTINUE HANDLER FOR NOT FOUND。MySQL不像应用层语言有hasNext()，它靠这个处理器捕获“无数据可取”状态，并把done变量设为TRUE。没它，FETCH一碰空结果集就抛ERROR 1329 (02000): No data - zero rows fetched，整个存储过程终止。
关键点：
-
DECLARE CONTINUE HANDLER必须写在游标DECLARE之后、OPEN之前，且只能声明一次 -
done变量要初始化为FALSE（或0），不能依赖默认值 - 处理器作用域只覆盖当前存储过程，不能跨过程复用
- 别用
EXIT HANDLER——它会直接退出过程，不是你想要的“跳过本次循环”
游标内执行UPDATE/DELETE极易引发死锁，必须加ORDER BY + 显式锁定
游标本身不加锁，但你在循环体内对同一张表做UPDATE或DELETE时，如果没控制访问顺序，InnoDB很容易因行锁竞争形成死锁。比如游标按id ASC遍历，而你的UPDATE语句没索引、走全表扫描，锁住的行顺序和游标不一致，两笔事务就可能互相等待。
安全做法：
- 游标
SELECT语句必须带ORDER BY，且排序字段要有索引（如主键） - 若后续要更新，改用
SELECT ... FOR UPDATE ORDER BY id显式加锁，确保锁顺序与遍历顺序严格一致 - 避免在游标循环中调用另一个修改相同表的存储过程——嵌套事务会让锁范围不可控
- 单次循环内只操作当前行对应的数据，不要跨行读写（比如根据当前行查出另一行再更新）
动态SQL游标无法传参？用用户变量+PREPARE绕过限制
MySQL游标不支持直接参数化表名或WHERE条件里的字段值，DECLARE cur CURSOR FOR SELECT * FROM ?语法非法。硬拼字符串进SELECT又容易SQL注入、且无法预编译。实际可行的方案是：先用用户变量存参数，再在OPEN前用PREPARE构造语句。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
示例逻辑：
SET @sql = CONCAT('SELECT id, name FROM products WHERE stock < ', @threshold);
PREPARE stmt FROM @sql;
EXECUTE stmt;
DEALLOCATE PREPARE stmt;但注意：CURSOR本身不能绑定PREPARE结果，所以更稳妥的方式是——把动态查询结果先插入临时表，再让游标查这张临时表。虽然多一步IO，但规避了语法限制和并发下临时表冲突问题。
游标遍历大数据量时，别忽略事务粒度和超时风险
一个游标循环几万行，全程包在一个事务里，会导致长事务、锁持有时间过长、binlog膨胀、甚至触发innodb_lock_wait_timeout。这不是游标本身的问题，而是使用方式越界了。
建议拆分策略：
- 每处理500~1000行
COMMIT一次，用START TRANSACTION包裹小批次 - 在循环内加计数器，到达阈值后
COMMIT并START TRANSACTION新事务 - 避免在游标循环中调用
SLEEP()或外部API——这会让锁白白占着不放 - 监控
SHOW PROCESSLIST里状态是否长期卡在Updating或Locked
真正难的不是写对语法，而是想清楚：这一行数据的处理，是否真的需要和其他行强一致性？多数批量场景其实可以接受最终一致性，那就别把所有行锁死在一个事务里。
