应统一存储过程参数命名为@p_前缀+小写下划线风格,如@p_user_id;输出参数加_out后缀;需配合依赖检查、调用方更新及头部注释,并通过CI阶段SQL Lint强制执行。存储过程参数命名不统一,导致调用方难以理解SQL 存储过程中参数名五花八门:@UserID、@user_id、@p_id、@in_userId......调用时得翻源码猜含义,协作和维护成本直线上升。核心是建立可执行的命名契约,不是写文档。推荐统一用 @p_ 前缀 + 小写下划线风格,比如 @p_user_id、@p_is_active、@p_created_after。前缀 @p_ 明确标识这是「parameter」,和变量 @temp_id、游标 @cur 严格区分开全小写 + 下划线(snake_case)兼容 SQL Server / PostgreSQL / MySQL(大小写敏感环境不出错)避免缩写歧义:@p_usr 不如 @p_user_id 直观;@p_st 是 status 还是 start_time?输出参数加 _out 后缀:@p_user_name_out,比单纯 @user_name 更易识别方向SQL Server 中 ALTER PROCEDURE 时不校验参数名变更影响改了 @uid 为 @p_user_id,但调用方代码还传 @uid,运行时报错 Procedure or function 'xxx' expects parameter '@uid', which was not supplied. ------ 这类错误不会在 ALTER 时暴露,只在运行时炸。必须配合三步动作:ALTER 前先查依赖:SELECT * FROM sys.dm_exec_describe_first_result_set(N'EXEC your_proc @uid=1', NULL, 0) 看当前期望参数更新所有调用方:应用层代码、其他存储过程里的 EXEC your_proc @uid = ...、SSIS 包、报表数据集在存储过程头部加注释块,明确标注参数契约:-- @p_user_id: INT, required, ID of target userMySQL 存储过程中 IN/OUT/INOUT 参数类型与命名需同步约束MySQL 允许 IN user_id INT 这种省略 @ 的写法,但混用风格会让团队困惑。更麻烦的是:类型不一致引发隐式转换,比如 IN user_id VARCHAR(20) 被传入数字 123,可能匹配到 '123 '(带空格)。 Mokker AI AI产品图添加背景
相关推荐
东莞市云毅网络有限公司5 小时前
AI 引用句逐条回指原文:让回答可回溯的校验实现李兆龙的博客7 小时前
问津集 #26:Lakebase——Postgres 的版本化页面存储、数据库分支与计算弹性数字融合7 小时前
透明化视频三维矿山井下照明重建技术yi0117 小时前
LeetCode 219:存在重复元素 II——哈希表记录“最近一次出现的位置”Marst Code8 小时前
上位机开发日记 · 第 2 篇 · 架构先行:六层分层与边界倔强的石头_9 小时前
聊聊金仓KFS:一款把数据同步软件做扎实的产品闲云野鹤在人间9 小时前
MySQL|从理论、安装、备份到主从复制、MHA高可用详解禾小西9 小时前
Redis:从两大维度和三大主线建立知识体系李日华大战鸡红9 小时前
FOC状态空间方程模型推导(学习记录)禾小西10 小时前
Redis 数据结构:快速的 Redis 有哪些慢操作?