mysql中declare变量仅在声明它的begin...end块内有效，遵循块级作用域；必须置于块首，嵌套块可重声明同名变量实现遮蔽；不可用于prepare动态sql，需拼接或?占位符；退出时自动销毁，但不影响事务。
MySQL 存储过程中 DECLARE 的变量只在当前 BEGIN...END 块内有效
MySQL 的 DECLARE 变量不是全局的，也不是跨 BEGIN...END 块共享的。它遵循严格的块级作用域规则：在哪一个 BEGIN...END 里 DECLARE 的，就只能在那个块及其嵌套的子块里用。
常见错误现象：Undeclared variable 错误，尤其在 IF 或 LOOP 内部试图访问外层 DECLARE 的变量时——其实不是“访问不到”，而是你写在了错误的位置（比如把 DECLARE 放在了 IF 后面）。
-
DECLARE必须放在每个BEGIN...END块的最开头，紧接在BEGIN之后、任何语句（包括SET、IF）之前 - 嵌套块可以重新
DECLARE同名变量，会遮蔽外层变量（不是报错，是静默覆盖） - 存储过程参数（
IN/OUT/INOUT）和DECLARE变量互不干扰，但名字别撞，否则调用时容易混淆
不能在存储过程里用 @ 变量替代 DECLARE 变量来传值
@ 变量是会话级用户变量，生命周期长、作用域宽，看着方便，但用在存储过程里反而容易出问题：它不随块退出而销毁，可能残留旧值；多个并发调用会互相污染；调试时难以追踪来源。
使用场景：适合临时脚本或单次调试，不适合正式存储过程逻辑。
- 存储过程里优先用
DECLARE+ 显式作用域，而不是依赖@var := ... -
SELECT ... INTO只能赋值给DECLARE变量，不能直接赋给@变量（语法报错） - 如果真要用
@变量（比如动态 SQL 中拼接），记得每次用前显式初始化，例如SET @sql = '';
DECLARE 变量无法在 PREPARE / EXECUTE 动态 SQL 中直接引用
这是 MySQL 的硬限制：PREPARE 只认字面 SQL 字符串，不认识当前作用域里的 DECLARE 变量。想把变量值塞进动态 SQL，必须用字符串拼接（CONCAT）或 SET @sql = CONCAT(...)，再执行。
性能影响：拼接字符串生成 SQL 是运行时行为，无法预编译优化，且容易引发 SQL 注入（如果变量来自不可信输入）。
- 安全做法：用
?占位符 +EXECUTE ... USING，但仅限于WHERE值、ORDER BY字段名等支持参数化的位置；表名、列名、LIMIT 数值等不支持，只能拼接 - 拼接时务必用
QUOTE()包裹字符串值，避免引号失配或注入，例如：CONCAT('SELECT * FROM t WHERE name = ', QUOTE(v_name)) - 拼接后的
@sql字符串长度受max_allowed_packet限制，超长会静默截断，建议加CHAR_LENGTH(@sql)检查
存储过程退出时，DECLARE 变量自动销毁，但不会释放内存或影响事务
变量本身不占持久资源，退出即丢，这点不用手动清理。但要注意：变量值如果被用于修改数据（比如 INSERT INTO ... VALUES (v_id)），那事务行为由 COMMIT/ROLLBACK 控制，和变量生命周期无关。
容易踩的坑：以为“变量没了，之前做的操作也该撤销”，结果发现数据已写入——变量只是容器，不是事务代理。
- 事务控制必须显式写
START TRANSACTION、COMMIT、ROLLBACK，不能靠变量作用域推断 - 如果过程里用了游标（
DECLARE CURSOR），游标变量也要在对应块内DECLARE，且打开/关闭需成对，否则可能锁表或报Cursor is not open - 调试时想看变量值？用
SELECT v_var AS debug;，别依赖客户端显示，因为有些客户端不展示存储过程内的SELECT结果集
事情说清了就结束
