MySQL要求局部变量必须在BEGIN后集中声明且位置严格，禁止混入可执行语句；应使用前缀命名、DEFAULT初始化、游标或临时表替代多值存储；变量过多表明逻辑需重构。
局部变量必须在BEGIN…END开头集中声明
MySQL强制要求所有DECLARE语句必须出现在存储过程或函数的BEGIN之后、其他任何可执行语句之前。一旦混入SET、SELECT或IF，就会报错ERROR 1337 (42000): Variable 'xxx' is not in scope。
常见错误是边写逻辑边补变量，比如先写了SET @x = 1，再回头加DECLARE x INT——这不行，@x是会话变量，和局部变量x完全无关，且DECLARE位置已错过。
- 所有
DECLARE必须紧贴BEGIN后，按类型/用途分组排列（如先放计数类INT，再放状态类VARCHAR） - 支持单条语句声明多个同类型变量：
DECLARE cnt, total, offset INT DEFAULT 0 - 带
DEFAULT比不带更安全，避免NULL参与计算引发意外（比如WHERE id = var时var为NULL永远不匹配）
别用局部变量存查询结果集，改用游标或临时表
局部变量只能保存单值，强行用SELECT col INTO var FROM t处理多行会直接报错ERROR 1172 (42000): Result consisted of more than one row。有人试图用循环+DECLARE堆一堆var1、var2…var100来“模拟数组”，这既不可读又无法扩展。
真实场景中，需要批量处理数据时：
- 用
DECLARE cur_name CURSOR FOR SELECT ...配合FETCH逐行取值，变量只做单次承载 - 若需多次引用中间结果，优先建
CREATE TEMPORARY TABLE tmp_xxx AS SELECT ...，再用SELECT COUNT(*) INTO var_cnt FROM tmp_xxx - 避免把业务逻辑拆成几十个局部变量拼接，那其实是设计缺陷——该拆成多个小存储过程或用应用层处理
命名要有区分度，避免和参数/字段名冲突
MySQL对大小写不敏感，且局部变量作用域虽限于块内，但和输入参数、表字段同名时极易混淆。例如定义IN user_id INT，又DECLARE user_id VARCHAR(32)，后续SET user_id = 'abc'实际修改的是参数还是变量？MySQL按就近原则取局部变量，但人眼极易误判。
- 约定前缀：计数类用
cnt_（cnt_total）、状态类用flag_（flag_done）、临时值用tmp_（tmp_salary） - 绝对不要复用表字段名，比如表有
status列，就别声明DECLARE status TINYINT，改用DECLARE proc_status TINYINT - 调用
SELECT ... INTO时，确保目标变量名在当前块唯一，否则可能意外覆盖外层同名变量（嵌套BEGIN...END时尤其危险）
大量变量意味着逻辑过载，该重构了
当一个存储过程中DECLARE超过15行，或者变量名开始出现v1、v2、temp1这类无意义命名，基本可以判定这段逻辑不该塞在一个过程里。
这不是语法限制问题，而是维护性警报：
- 每个存储过程专注单一职责：统计、校验、生成、同步，任选其一
- 把共用变量逻辑抽成
FUNCTION返回标量，或用OUT参数传递结构化结果 - 真正复杂的流程（比如订单履约链路）建议交还给应用层控制，数据库只保证原子操作，别让它扛状态编排
局部变量本身没有数量上限，但人脑对变量关系的跟踪能力有硬边界。写完记得问自己：删掉任意3个变量，这个过程还能正确运行吗？如果答案是否定的，说明耦合已失控。
