MySQL解析同名参数与字段时，优先将裸名视为字段而非参数，导致WHERE user_id = user_id等价于WHERE 1=1，引发全表更新或删除；根本解决方式是参数统一加前缀（如p_user_id）以杜绝命名冲突。
WHERE 条件失效、UPDATE 变成全表更新、SELECT 返回全部行——这些不是报错，而是静默出错。根本原因：MySQL 在解析 SQL 语句时，优先把未加限定的名字当作字段名，而不是参数，且不区分大小写。
MySQL 怎么解析同名参数和字段？
当你写 WHERE user_id = user_id，MySQL 不会认为左边是字段、右边是参数；它把两个都当成 users.user_id 字段，等价于 WHERE 1=1。
这不是 bug，是明确的解析规则：在存储过程作用域内，未加表别名或前缀的裸名，只要能匹配到字段，就优先绑定字段；参数仅在显式上下文（如赋值、函数调用）中才被识别为变量。
-
DELETE FROM users WHERE user_id = user_id→ 删除整张表 -
UPDATE users SET name = name WHERE id = id→ 全表更新，但值不变 -
SELECT * FROM users WHERE status = status→ 返回所有status IS NOT NULL的行（实际行为依赖 NULL 处理）
为什么加表别名也不总管用？
加别名看似能解决歧义，但在 DELETE 和 UPDATE 语句里语法限制多，容易写错：
-
DELETE FROM users t WHERE t.user_id = user_id❌ 语法错误（缺少DELETE t） -
DELETE t FROM users t WHERE t.user_id = user_id✅ 正确，但易漏掉t -
UPDATE users t SET t.name = 'x' WHERE t.id = user_id✅ 安全，但冗长 -
SELECT * FROM users u WHERE u.id = id✅ 有效，但依赖你记得加u.
一旦漏掉别名或写错位置，就回到静默错误状态，调试时几乎无法从日志或返回结果察觉。
怎么避免参数与字段名冲突？
最可靠的方式不是“加别名”，而是从命名源头切断歧义：
- 参数统一加前缀：
p_user_id、p_status、in_order_no（in/out前缀也行） - 局部变量加前缀：
v_count、l_start_time，避免和@session_var混淆 - 建表时字段名尽量不用通用词（如
id、name、status），而用业务上下文名（order_id、product_name、order_status） - 写完存储过程后，用
SELECT语句单独抽出来，在客户端执行一遍，确认逻辑是否如预期
临时绕过冲突的危险做法
有人用预处理语句拼接 SQL（如 CONCAT('WHERE age = ', p_age)）来规避解析歧义，但这引入新风险：
- SQL 注入漏洞（除非严格校验输入）
- 执行计划无法复用，每次都是硬解析
- 错误信息指向动态 SQL 行号，而非存储过程源码行
- 事务中若预处理失败，回滚边界可能不清晰
这不是解决方案，是把问题从“语义歧义”转移到“运行时不可控”。真要动态 SQL，至少用 QUOTE() 包裹字符串值，并禁用非数字参数直接拼接。
真正麻烦的不是写错一次，而是这种错误不报错、不告警、只在特定数据下偶然暴露——上线后才发现删了生产表，或者定时任务每天覆盖关键字段。命名规范看着琐碎，其实是唯一能提前堵死这类漏洞的防线。
