存储过程参数名必须与列名区分，推荐加前缀如p_user_id；同名时需用表别名限定；in/out/inout类型需严格匹配用途，out/inout须初始化；参数统一小写加下划线，禁用模糊缩写与泛化命名。
存储过程参数名不能和列名重复
MySQL在存储过程中，如果参数名和表字段名相同，WHERE 或 SET 语句里直接用名字会被优先解析为参数，导致查不到数据或意外覆盖。这不是警告，是静默行为，调试时极难发现。
- 参数命名务必加前缀，比如
p_user_id、p_status，避免和user_id、status冲突 - 已有同名列的场景下，显式用表别名限定，例如
SELECT t.name FROM users t WHERE t.id = p_id - 不推荐用
@变量模拟参数——它绕过作用域检查，更难维护
IN/OUT/INOUT 参数类型决定赋值方式
IN 是只读传入，OUT 是仅输出（调用后才可读），INOUT 才能既读又写。混淆类型会导致调用方拿不到值，或过程内修改无效。
-
OUT和INOUT参数在过程开头必须初始化，否则值为NULL，后续CONCAT或算术运算会全变成NULL - 调用时
OUT参数必须传变量，不能传字面量：CALL sp_get_name('abc', @out_name)✅，CALL sp_get_name('abc', 'xxx')❌（报错） - 若只需返回单个值，优先用
OUT；需双向传递且逻辑耦合紧，再选INOUT
参数名大小写在不同系统上表现不一致
Linux 下 MySQL 默认区分数据库/表名大小写，但参数名本身不区分——然而 IDE（如 DBeaver、Navicat）或生成文档工具可能按字面匹配，大小写混用会引发引用失效。
- 统一用小写 + 下划线，例如
p_created_after，别写成P_CREATED_AFTER或pCreatedAfter - 建过程前先执行
SELECT @@lower_case_table_names，值为1表示不区分，但仍建议命名自律 - Git 提交时注意文件名大小写敏感问题：同一个过程改名大小写，某些系统会认为是新文件
长参数名影响性能？其实几乎没影响，但影响可读性
参数名长度对执行计划、内存占用、网络传输都无实质影响，MySQL 解析阶段就替换成内部符号了。真正掉坑的是人——太长或太短都会让调用方困惑。
- 避免缩写歧义：比如
p_dt不清楚是datetime还是detail，应写成p_create_time - 拒绝无意义泛化：别用
p1、p_arg这类名字，哪怕临时调试也请立刻改掉 - 团队共用的存储过程，参数顺序最好和常用调用场景一致，比如
(p_user_id, p_start_date, p_end_date)比(p_end_date, p_user_id, p_start_date)更符合直觉
最麻烦的不是语法错，是三个月后你看着 p_x 和 v_y 分不清哪个是入参、哪个是局部变量、哪个其实早该删了——命名这事，当时多打三个字母，后面少查两小时日志。
