变量作用域冲突不是语法错误，而是逻辑静默污染——它不报错，但结果不可信；MySQL中DECLARE变量与参数同名会覆盖参数导致值丢失，PL/pgSQL同名列/变量引发歧义错误，SQL Server内层同名变量静默覆盖，用户变量@var跨过程残留易致意外行为。
变量作用域冲突不是语法错误，而是逻辑静默污染——它不报错，但结果不可信。 你看到 SELECT 返回值突然变空、IF 判断总走错分支、甚至两次调用同一存储过程返回不同结果，大概率是局部变量和参数、用户变量或列名撞了名字，且数据库按默认规则“猜”错了引用目标。
MySQL 中 DECLARE 变量与参数同名导致覆盖
MySQL 不允许在同一个作用域内重复声明，但允许参数名和 DECLARE 变量同名。此时，DECLARE 会覆盖参数，后续所有对该名称的引用都指向局部变量，原始参数值彻底丢失。
- 典型现象：
IN参数传入100，但过程中SELECT id却返回NULL或旧值 - 根本原因：参数
id被DECLARE id INT隐式屏蔽，而新声明的id未初始化，值为NULL - 安全做法：参数统一加前缀（如
p_id），局部变量用v_id，游标变量用c_id—— 不依赖数据库“猜”，靠命名自解释 - 禁止写法：
DECLARE user_id INT; SET user_id = p_user_id;→ 改为SET v_user_id = p_user_id;
PL/pgSQL 里列名与变量名完全相同时报 “column reference is ambiguous”
PostgreSQL 的 PL/pgSQL 默认把同名列/变量当作歧义错误（variable_conflict = error），尤其在 UPDATE ... WHERE col = col 这类语句中，col 既可能是表字段，也可能是函数参数或 DECLARE 变量。
- 不要改全局配置去绕过，而应显式限定：
WHERE t.col = $1（用位置参数）、WHERE my_table.col = my_var（加别名或前缀） - 建表或写函数时，避免让列名和常用变量名重合，比如表有
status字段，就别用status当参数名 - 若必须兼容旧命名，可在函数开头加
variable_conflict use_variable，但仅限该函数内部生效，且要同步注释说明 —— 这是妥协方案，不是推荐解法
嵌套 BEGIN...END 块中同名变量引发覆盖而非隔离
MySQL 和 SQL Server 都不真正支持嵌套作用域：内层 BEGIN...END 块里 DECLARE 同名变量，不会创建新作用域，而是直接报错（MySQL）或静默覆盖（SQL Server）。PL/pgSQL 则允许，但需手动用块标签区分。
- MySQL 报错示例：
ERROR 1336 (0A000): Variable 'v_flag' must be declared before cursor or handler declaration—— 因外层已声明，内层再声明就违反顺序约束 - 正确做法：外层声明统一变量，用不同后缀区分用途，如
v_flag_precheck、v_flag_postupdate；或拆成多个独立存储过程，用参数传递 - PL/pgSQL 可用块标签 +
variable_conflict use_column临时切换解析优先级，但只应在明确需要列名优先的单条语句前加，用完即切回，避免扩散影响
用户变量 @var 与局部变量混用导致会话残留
@var 是会话级的，跨存储过程存活，且不随 DECLARE 变量销毁而清空。一次调试中设了 @debug = 1，下次调用其他过程时，IF @debug THEN 突然生效，就是这个原因。
- 永远不要在正式存储过程中依赖
@var传值；要用就严格配对：SET @var = NULL在入口处重置，出口前再清一次 - 比
@var更安全的是临时表：CREATE TEMPORARY TABLE tmp_result (...)，它随会话结束自动销毁，且能存多行多列，无命名冲突风险 - 如果真要调试，用
SELECT CONCAT('DEBUG: v_count=', v_count)直接输出，而不是塞进@debug_msg再查
最危险的不是报错，而是没报错却算错了——变量作用域问题往往只在特定数据路径下暴露，上线后才浮现。与其事后排查，不如从第一行 DECLARE 开始，就用带业务前缀的命名、块内不复用名、拒绝任何“刚好同名”的侥幸。数据库不会替你记住上下文，但命名可以。
