SQL存储过程是预先编写、编译并保存在数据库中的一组SQL语句集合。它把多次使用的查询、更新或事务逻辑封装为一个可重复调用的数据库对象，使应用代码不必反复拼接和发送相同的SQL片段。通过存储过程，开发者可以把高频操作、数据校验和一致性规则集中到数据库侧执行，从而提升访问效率并降低维护成本。
SQL存储过程是什么
从对象角度看，存储过程通常由数据定义语言（DDL）和数据操作语言（DML）组合而成。创建过程时，数据库引擎会对过程体进行语法检查、对象解析和一定程度的优化，生成可重用的执行计划。后续调用时，数据库直接根据已保存的过程定义与缓存计划执行，省去每次从文本解析开始的步骤。存储过程可以接收输入参数，也可以定义输出参数或返回结果集，不同数据库对返回能力的支持略有差异，但核心思想一致。
与传统的一条条SQL语句相比，存储过程的主要价值不在于“把SQL放在哪里”，而在于执行边界和职责边界的变化。应用调用存储过程时，只需要传递过程名和参数，不必关心过程内部具体如何访问哪些表。这带来几个明显优势：
- 减少网络往返：多步SQL在数据库内部直接完成，客户端只需一次调用
- 执行计划复用：过程对象创建后通常保留编译结果，执行性能更稳定
- 权限边界清晰：可以只授予执行存储过程的权限，而不直接开放底层表
- 业务规则集中：相同计算逻辑只维护一份，降低各调用端实现不一致的风险
当然，这并不意味着所有业务都应迁移到存储过程。数据库的强项在于集合运算和事务控制，而流程编排、外部服务调用、复杂展示逻辑仍应保留在应用程序中。理解这一点，有助于合理划分职责。
如何创建SQL存储过程
在MySQL中，使用CREATE PROCEDURE语句创建存储过程。由于过程体内部通常包含多条以分号结尾的SQL语句，而MySQL客户端本身也以分号作为语句结束符，因此需要先通过DELIMITER命令把结束符临时改为其他符号，待过程定义完成后再恢复为分号。下面示例创建一个名为count_by_dept的存储过程，它接收部门编号作为输入参数，并把符合条件的员工人数写入输出参数。
DELIMITER //
CREATE PROCEDURE count_by_dept(IN dept_id INT, OUT total INT)
BEGIN
-- 根据传入的部门编号统计员工数量
SELECT COUNT(*) INTO total
FROM employee
WHERE department_id = dept_id;
END //
DELIMITER ;
上述过程体内使用SELECT ... INTO把聚合结果赋值给输出参数。存储过程体必须包裹在BEGIN ... END块中，可以包含局部变量声明、条件语句、循环语句以及事务控制语句。
参数类型说明
创建存储过程时，参数可以声明为IN、OUT或INOUT三种模式。不同模式决定了参数是只读、只写还是可读写，也直接影响调用端如何传值和接收结果。
| 类型 | 含义 |
|---|---|
| IN | 调用时传入，过程内部只读 |
| OUT | 过程内部赋值，返回给调用者 |
| INOUT | 既可传入也可返回 |
除了参数外，过程体内部还可以使用DECLARE声明局部变量，使用SET或SELECT INTO赋值，并通过IF、CASE、LOOP、WHILE等控制执行流程。良好的注释和命名习惯能让存储过程更易于长期维护。
如何调用SQL存储过程
在MySQL中，调用存储过程使用CALL命令。如果过程存在输出参数，调用前需要准备一个用户变量来接收输出值，然后通过SELECT查看该变量。下面的示例调用前面创建的count_by_dept，统计部门编号为10的员工人数。
-- 调用存储过程并接收输出参数 CALL count_by_dept(10, @cnt); -- 查看输出参数的值 SELECT @cnt AS employee_count;
调用完成后，@cnt就保存了统计结果。对于只有输入参数或没有参数的过程，可以直接使用CALL procedure_name(...)执行。在应用程序中，不同编程语言和数据库驱动通常提供专门接口来执行存储过程，例如使用参数化命令或可调用语句对象，其本质都是向数据库发送CALL或相应的执行指令。
其他数据库的差异
存储过程的概念在主流关系型数据库中基本一致，但调用语法和环境有所差异。SQL Server中通常使用EXEC或EXECUTE命令调用；Oracle中可以通过BEGIN ... END;匿名块执行，也可以在PL/SQL环境中直接调用；PostgreSQL从较新版本开始同样支持CALL命令，并且过程可以通过IN、INOUT参数返回结果。这些语法差异不影响存储过程的整体设计思路。
使用注意事项
存储过程虽然能带来效率与封装上的好处，但不应把大量复杂业务逻辑全部压入数据库。过程体一旦复杂，调试、单元测试和版本管理都会变得困难，数据库还可能成为性能瓶颈。更合理的做法是让存储过程承担高频、计算密集或需要强事务一致性的操作，而把易变业务规则保留在应用层。
存储过程虽好，但不宜把过多复杂业务全部塞入数据库，否则难以调试和版本管理。
当存储过程包含写操作时，建议显式使用事务，并为异常情况设置回滚路径。MySQL中可以通过DECLARE EXIT HANDLER或DECLARE CONTINUE HANDLER捕获SQLEXCEPTION，在出现错误时回滚事务。下面示例创建一个带异常保护的存储过程，当业务更新出现异常时自动回滚。
DELIMITER //
CREATE PROCEDURE safe_update_salary()
BEGIN
-- 出现 SQL 异常时执行回滚并退出
DECLARE EXIT HANDLER FOR SQLEXCEPTION
BEGIN
ROLLBACK;
END;
START TRANSACTION;
-- 业务写入逻辑
UPDATE employee
SET salary = salary * 1.1
WHERE department_id = 10;
COMMIT;
END //
DELIMITER ;
此外，权限控制同样值得重视。只为应用账号授予EXECUTE权限，而不是直接授予底层表的增删改查权限，可以减少越权操作风险。在团队协作中，存储过程也需要纳入版本管理，与应用程序代码同步评审和发布。总的来说，存储过程是一种有力的数据库端抽象工具，合理使用能提升系统稳定性和可维护性，过度使用则可能带来新的复杂度。开发者应根据业务特征、团队能力和数据库选型，选择最合适的落点。
综合来看，SQL存储过程的创建与调用并不复杂，关键在于正确理解参数模式、掌握不同数据库的语法差异，并在设计时平衡数据库端与应用端的职责。对于高频查询、数据校验和事务写入，存储过程能够提供稳定的性能与清晰的权限边界；对于多变业务和复杂流程，则应保持谨慎。只有结合具体场景进行取舍，才能真正发挥存储过程的价值。