参数化存储过程通过显式声明参数并绑定变量，使数据库严格区分代码与数据，从而避免SQL注入；同时利用执行计划缓存提升性能，1000次调用下CPU消耗降低85%、编译次数从1000次降至1次。
存储过程本身不是面向对象语言，谈“设计模式”容易误导——它没有 Factory、Singleton 那类抽象结构。真正高频复用的，是围绕数据操作场景沉淀下来的**SQL级惯用写法**，本质是解决“怎么组织语句更安全、可维护、易扩展”。
如何用参数化输入避免硬编码和SQL注入
所有带用户输入的 IN 参数必须走变量赋值，禁止拼接字符串。MySQL 中 CALL myproc('admin' + @user) 这种写法不存在，也绝不能用 CONCAT 拼进 SQL 字符串里执行。
-
IN参数只用于值传递，不参与语句拼接；需要动态表名/列名时，必须先白名单校验再用PREPARE+EXECUTE - SQL Server 的
@param和 MySQL 的IN param_name TYPE语义一致，但 MySQL 不支持直接参数化表名 - 常见错误：把用户名当字符串拼进
WHERE name = '+ input +'—— 这等于裸奔
为什么多数业务逻辑不该塞进存储过程
不是不能放，而是放了之后调试成本陡增：你没法在 IDE 里单步、看不到完整上下文、日志分散在数据库日志里。尤其涉及多表事务+外部系统调用（如发消息、调 API）时，存储过程 只能做数据层原子操作，编排逻辑交给应用层更可控。
- 适合放进存储过程的：单库内多表一致性校验、批量状态更新、历史数据归档
- 不适合的：含 HTTP 请求、文件读写、复杂分支判断（超过 3 层嵌套）、需频繁修改的规则引擎
- 性能陷阱：用
CURSOR遍历万级记录 —— 多数情况可用JOIN或窗口函数替代
如何设计可复用的错误处理与返回协议
别依赖 RAISERROR（SQL Server）或 SIGNAL（MySQL）抛出原始错误码。统一用输出参数或结果集返回结构化状态，比如固定三字段：ret_code INT、ret_msg VARCHAR、ret_data JSON（MySQL 5.7+）。
- SQL Server 中
RETURN只能传整数，且无法和结果集共存；MySQL 的OUT参数更灵活 - 避免在存储过程中写
PRINT或SELECT 'debug info'—— 应用层无法区分这是业务数据还是调试输出 - 事务边界要显式：开头
BEGIN TRY/START TRANSACTION，结尾COMMIT或ROLLBACK，不能靠客户端自动提交
关键点在于：所谓“模式”，其实是对「数据动作」的约束性封装——比如一个叫 sp_transfer_fund 的存储过程，内部必须包含余额校验、双账本更新、流水写入、异常回滚四步，缺一不可。漏掉任何一步，就不是真正的模式，只是零散 SQL 堆砌。