MySQL游标声明顺序必须为变量→游标→HANDLER，FETCH后须立即检查done，SELECT需静态且字段与变量严格匹配，游标只读，更新须用主键二次查询，优先避免使用游标。
DECLARE游标必须在变量和HANDLER之后
MySQL对声明顺序极其敏感。如果把CURSOR声明写在DECLARE done INT DEFAULT FALSE之前，或者插在两个变量声明中间，会直接报错：Variable or condition declaration after cursor or handler declaration。这不是警告，是语法硬限制。
正确顺序只能是：变量 → 游标 → HANDLER。哪怕你只声明一个变量、一个游标、一个HANDLER，也必须严格按这个次序写。常见错误是先写游标再补变量，结果整个存储过程编译失败。
- 变量声明（含
done标志）必须全部放在最前 -
CURSOR声明紧随其后，且SELECT语句必须是静态的——不能拼接表名、列名或用CONCAT()构造 -
CONTINUE HANDLER FOR NOT FOUND必须在游标之后、OPEN之前，且只能设一个变量（比如done），不能写成SET done = TRUE, processed = 0
FETCH后必须立刻检查done，不能放到循环末尾
很多人习惯把IF done THEN LEAVE写在LOOP块末尾，这会导致最后一行被重复处理一次。因为FETCH在结果集末尾仍会执行，只是不赋值，而done要到下一次FETCH才被HANDLER触发——也就是说，当游标已空时，你已经进了一次循环体，数据还是上一轮的旧值。
正确做法是每次FETCH后**立即**判断done，再决定是否继续。用WHILE NOT done DO也行，但要注意done初始值必须是FALSE，且HANDLER必须存在。
- 错误模式：
FETCH ...; -- 处理逻辑; IF done THEN LEAVE→ 最后一行被处理两次 - 正确模式：
FETCH ...; IF done THEN LEAVE; END IF; -- 处理逻辑 - 如果用
REPEAT ... UNTIL done，需确保第一次FETCH在REPEAT之前执行，否则循环体一次都不进
复合结果集字段名与变量名必须严格一一对应
所谓“复合结果集”，比如SELECT u.id, u.name, COUNT(o.id) FROM users u LEFT JOIN orders o ON u.id = o.user_id GROUP BY u.id，返回三列。这时FETCH的INTO变量列表必须数量、顺序、类型完全匹配，否则静默截断或报错Data truncated for column。
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
尤其注意NULL值：LEFT JOIN产生的COUNT可能为NULL，若接收变量是INT类型，MySQL默认转成0；但若你定义的是DECIMAL或没设默认值，就可能出问题。别依赖隐式转换。
- 变量名不必和字段名相同，但顺序和类型必须一致
- 建议显式写出字段别名（如
COUNT(o.id) AS order_cnt），并在注释里标明对应变量，避免后期改SQL时漏调变量 - 字符串类变量长度要留余量，比如
VARCHAR(255)接user.name可以，但接CONCAT(u.name, ' - ', o.status)就可能截断
游标遍历中更新数据必须用主键二次查询，不能用CURRENT OF
MySQL游标是只读的，不支持UPDATE ... WHERE CURRENT OF cursor_name这种Oracle风格语法。你想更新当前行，只能靠FETCH出来的主键值再发一条独立UPDATE。
这意味着：如果你在循环里做UPDATE，又恰好这个表同时被其他事务修改，就可能出现“幻读”或更新错行——因为游标打开时快照已定，但UPDATE语句跑在当前事务隔离级别下，看到的是最新数据。
- 务必在
SELECT里明确包含主键（如id），否则你连更新哪行都不知道 - 如果业务要求强一致性，考虑加
SELECT ... FOR UPDATE，但会锁行，影响并发 - 能不用游标就不用：像统计回填这类场景，优先写
UPDATE t1 JOIN (SELECT ...) t2 ON t1.id = t2.id SET ...，性能差十倍以上
真正麻烦的不是语法，而是游标打开后那个隐式快照和后续DML之间的时序差——它不会报错，但数据可能不对。上线前一定要用真实数据量+并发压测，光看单条逻辑通是不够的。
