香香甜甜圈存储过程这玩意儿，放到“存储对象”系列里往往比视图、序列这些“静态对象”显得更特殊，因为它存的不是数据表结构，而是一段真正能跑起来的逻辑。很多同学在这个进阶阶段第一次被卡住，通常不是因为SQL不会写，而是不知道“要怎么把一段逻辑固化到数据库里”，更不知道“参数、变量、控制语句这些到了存储过程里为什么写法变得那么别扭”。
这篇文章就把“存储过程上”这一关扯清楚，重点讲概念定位、创建姿势、参数方向和基础流程控制，涉及Oracle、MySQL、SQL Server、openGauss等主流数据库的差异也会点一下。文中所有例子都适合你在一台自建测试库上直接跑，尤其适合已经从“单条SQL查询”走到“系统集成开发”的朋友。
1. “存储对象”这个系列，为什么偏偏要把过程单拎出来讲
1.1 存储对象不只有表，还有过程和函数这些“可执行对象”
数据库里说的存储对象，通常包含表、视图、索引、序列、同义词、约束，以及另一大类叫“命名PL/SQL块”或“存储子程序”的东西——存储过程、存储函数、触发器、包。前一类保存的是结构或元数据，后一类保存的是业务逻辑。
很多人刚接触时容易把存储过程当成“一个很长的SQL”，这本质上就理解偏了。存储过程和普通SQL相比，核心差异在于：SQL是描述性的，你想让数据库返回一个结果集，只要写出“要什么”；但存储过程是命令式的，你可以定义变量、做循环、做条件判断、捕获异常，甚至在一个过程里去调用另一个过程。
打个比方：视图是一份可复用的“查询模板”，存储过程则是一个打包好的“业务流程处理机”。它接收你喂进去的参数，内部通过变量、逻辑分支、游标、异常把这些数据处理完，最后要么返回结果集、要么返回输出参数、要么直接改表数据。
1.2 为什么项目一旦复杂起来，你就绕不开过程
我在实际开发里遇到过很多类似需求：批量对账要一次性处理几万条明细，不符合规则的记录要单独落到错误日志表；订单超时状态要每隔几分钟批量刷新；老系统要做数据迁移，但源表字段和新表字段的转换规则有二十多条。这种场景如果用应用层代码写，应用要跟数据库来回交互几万次，慢不说，事务边界也难控制。
把逻辑放进存储过程的最大优势是“逻辑离数据最近”。存储过程在数据库实例内部执行，不需要把每行数据拉到应用服务器再做判断，能显著减少网络开销。而且它是编译后存储在数据库中的对象，第一次执行后执行计划可以复用，比应用层拼一堆SQL再逐条发送要稳定得多。
这里也要说句公道话：不是所有逻辑都适合塞进数据库。计算密集型、需要调用外部API、需要读取配置文件之类的业务，当然更适合留在应用层。存储过程真正擅长的场景是：强事务、批量数据操作、复杂查询加工、需要精细控制执行顺序的数据管道。搞清楚这个边界再决定要不要用过程，比盲目迷信“全放存储过程”或“全不放存储过程”都更理智。
1.3 为什么课程标题叫“进阶-存储对象2-存储过程上”
如果你看系统课程的门纲，一般会由浅入深推进：先讲表和数据操作，再讲查询，再到索引、视图、序列，之后才是存储过程。所以“存储对象2”这个编号表示前面已经讲过了静态对象的基本概念，现在进入动态过程对象。
“存储过程上”则意味着这个主题大概率会分两块讲：第一部分把过程的创建、参数、变量、基础条件分支和调用方式讲透；第二部分会深挖游标、循环嵌套、异常处理、动态SQL和性能优化。我这篇文章就陪你走完“上”这一段，把地基打稳，下半段才能踩得住。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 创建一个存储过程，其实只需要掌握四个位置“填空”
2.1 一个典型的Oracle存储过程骨架
先看一段非常朴素的Oracle存储过程，逻辑是按部门编号返回该部门的员工数量。虽然简单，但骨架非常完整：
oracle复制CREATE OR REPLACE PROCEDURE get_emp_count_by_dept(
p_dept_id IN NUMBER,
p_count OUT NUMBER
) IS
v_extra_name VARCHAR2(100);
BEGIN
-- 业务处理部分，这里写赋值、查询、运算
SELECT COUNT(*)
INTO p_count
FROM employees
WHERE department_id = p_dept_id;
-- 也可以通过变量承接中间值
SELECT department_name
INTO v_extra_name
FROM departments
WHERE department_id = p_dept_id;
DBMS_OUTPUT.PUT_LINE('部门名称：' || v_extra_name || '，人数：' || p_count);
EXCEPTION
WHEN NO_DATA_FOUND THEN
p_count := -1;
END get_emp_count_by_dept;
你不需要背下来，只需要理解它由四段组成：
- 声明段：
IS关键字之后，写局部变量，像v_extra_name； - 执行段：
BEGIN ... END之间，这是过程真正干活的区域； - 异常段：执行段末尾的
EXCEPTION部分，捕获和处理意料之外的错误； - 结束标记：
END后面加过程名，也可以不加，但建议加，多文件编辑时清晰度提升很多。
Oracle存储过程的特点之一是所有语句都以分号 ; 结尾，并且赋值符号是 :=，注意它跟“是否相等”的 = 完全是两码事。很多第一次从Java或C#转过来的同学会写 p_count = -1，这是编译过不去的。
2.2 MySQL和openGauss、SQL Server的创建姿势差异
Oracle用 CREATE OR REPLACE PROCEDURE，MySQL从5.0开始也支持，但语法稍微有点不同。MySQL里如果同时存在同名但有不同参数的过程，允许通过 DROP PROCEDURE IF EXISTS 重建，SQL Server也类似。代码如下：
mysql复制DELIMITER //
CREATE PROCEDURE get_emp_count_by_dept(
IN p_dept_id INT,
OUT p_count INT
)
BEGIN
SELECT COUNT(*)
INTO p_count
FROM employees
WHERE department_id = p_dept_id;
END //
DELIMITER ;
这里最容易被新朋友忽略的是 DELIMITER。因为MySQL客户端默认用分号作为语句结束符，而过程体内部有分号。如果你不提前把分隔符改掉，客户端会在你还没写完整个过程时就提前截断，于是你会看到一堆莫名其妙的语法错误。把分隔符改成 // 或 $$，就能确保整个过程被当成一个完整的定义提交给服务器。
openGauss创建存储过程的能力也类似，但作为基于PostgreSQL内核的数据库，它在参数方向、函数重载等细节上会和Oracle有很多细微差别。我帮一个政府类项目迁移时，把Oracle过程往openGauss搬，最常改的不是业务语句，而是 DBMS_OUTPUT 这类内置包和异常处理写法。openGauss虽然兼容了一部分Oracle语法，但实际使用仍要参照官方语法文档。
SQL Server则是用 CREATE PROCEDURE 或 CREATE PROC，参数直接在过程名后跟 @参数名 类型 [OUTPUT]，变量也要用 @ 开头。例如：
sql复制CREATE PROCEDURE get_emp_count_by_dept
@dept_id INT,
@count INT OUTPUT
AS
BEGIN
SELECT @count = COUNT(*)
FROM employees
WHERE department_id = @dept_id;
END
你会发现三个数据库的骨架逻辑完全一致，差别只在“声明方式”和“变量前缀符号”。所以学存储过程不要按“学某一个数据库语法”来背，先掌握通用骨架，再对照细微差别，这样你换库的时候才不会慌。
2.3 创建时最容易掉的坑：分号位置、过程名重复、权限不足
创建过程时报错的绝大多数原因，不是业务逻辑出错，而是“过程没建立起来”：
- 分号位置错误。Oracle里
END;必须有分号，但如果是CREATE OR REPLACE PROCEDURE整体作为一个脚本提交，过程体结束后需要再跟一个斜杠/。这个斜杠不是说给SQL语句用的，而是告诉SQL*Plus这种命令行工具“把整个PL/SQL块提交执行”。 - 过程名与已有表名重名。Oracle的存储过程和表是同一个命名空间，过程和表不能重名。如果你先建了一张名为
get_data的表，再想创建同名过程，就会报“名称已被现有对象使用”。 - 权限不足。创建过程通常需要
CREATE PROCEDURE系统权限；如果你要用CREATE OR REPLACE去替换属于其他用户的过程，还需要相应权限。这不是SQL本身的问题，但很多初学者容易忽略，尤其是生产环境回收权限比较严格时。
创建成功之后，你可以通过查看数据库字典验证过程是否存在。Oracle看 USER_PROCEDURES，MySQL看 INFORMATION_SCHEMA.ROUTINES，这样能确认对象确实被编译并存储。
3. 参数方向才是存储过程和普通函数的分水岭
3.1 IN、OUT、IN OUT到底各自负责什么
存储过程的参数有三个方向，理解错一个，后面写业务就是连环坑：
- IN（入参）：调用者传进来，过程内部只能读取，不能修改后传回去。这是默认方向，Oracle里不写就等于IN，MySQL必须明确写
IN。 - OUT（出参）：过程内部给值，调用者等过程执行完之后读取。它就像Java方法里的返回值，但可以有多个。
- IN OUT：既读又写。调用时带一个初始值进去，过程内部可以把它重新赋值后再带出去。
实际业务里用得最多的是IN，OUT用来返回结果值或状态码。比如做一个“批量更新客户积分”的过程，你可以设计一个OUT参数返回处理条数，另一个OUT参数返回失败码，这样调用方不需要查询就能知道执行效果。
oracle复制CREATE OR REPLACE PROCEDURE update_customer_points(
p_customer_id IN NUMBER,
p_points IN NUMBER,
p_result_code OUT NUMBER
) IS
BEGIN
UPDATE customers
SET points = points + p_points
WHERE customer_id = p_customer_id;
IF SQL%ROWCOUNT = 0 THEN
p_result_code := 404; -- 客户不存在
ELSE
p_result_code := 0; -- 成功
END IF;
END update_customer_points;
这里用到了 SQL%ROWCOUNT，它是一个隐式游标属性，表示上一条DML语句影响的行数。这是存储过程里非常实用的判断手段，后面写异常处理也会用到它。
3.2 三种数据库调用方式对比：EXEC、CALL、匿名块
过程建好了，不可能一直躺在数据字典里不动，总要被调用。不同数据库调用方式差别非常大：
| 数据库 | SQL/命令行中调用方式 | 示例 |
|---|---|---|
| Oracle | PL/SQL匿名块 | BEGIN get_emp_count_by_dept(10, :v); END; |
| MySQL | CALL 语句 |
CALL get_emp_count_by_dept(10, @cnt); SELECT @cnt; |
| SQL Server | EXEC 语句 |
EXEC get_emp_count_by_dept @dept_id=10, @count=@cnt OUTPUT; |
Oracle里如果在SQL*Plus直接执行 EXEC 也是在内部封装了一个匿名块，本质上没有区别。这里要特别注意Oracle的OUT参数在命令行里怎么接收：通常用一个绑定变量，比如上面示例中的 :v，然后再用 PRINT v 或 SELECT :v FROM dual; 查看。这和MySQL用 @cnt 用户变量的思路很像，但SQL Server就习惯多了一个 OUTPUT 关键字。
如果从应用程序里调用，Java用 JDBC CallableStatement，C#用 SqlCommand 或 MySqlCommand。C#执行MySQL存储过程的代码非常规整：
csharp复制using var conn = new MySqlConnection("server=localhost;database=test;uid=root;pwd=xxx");
using var cmd = new MySqlCommand("get_emp_count_by_dept", conn);
cmd.CommandType = CommandType.StoredProcedure;
cmd.Parameters.AddWithValue("@p_dept_id", 10);
cmd.Parameters.Add("@p_count", MySqlDbType.Int32).Direction = ParameterDirection.Output;
conn.Open();
cmd.ExecuteNonQuery();
Console.WriteLine(cmd.Parameters["@p_count"].Value);
这里最容易被坑的是 CommandType，如果不设置为 StoredProcedure，ADO.NET会把过程名当成一条普通SQL去解析，直接报找不到列或语法错误。
3.3 参数类型和长度能省则省？千万别省
写存储过程参数时，很多人图省事，不写长度。Oracle里 VARCHAR2 不写长度的话默认是4000字节，但埋下的隐患是：一旦大字段需求变成CLOB，你就要改过程签名。更重要的是，参数和列做关联查询时，类型不匹配会造成隐式转换，进而让索引失效。
我见过一个线上事故，过程入口参数写成 VARCHAR2 不带长度，传入的却是某业务系统的16位数字字符串，为了让它匹配数值主键，Oracle在条件里悄悄做了 TO_NUMBER 转换，结果一执行就是全表扫描。所以，参数类型设计要尽量跟表字段类型对齐，长度宁大勿小，但如果驱动里读取这个参数值再去查询，应该优先让类型一致。
生产规范里，建议参数名统一加前缀区分方向：入参 p_，出参也 p_，局部变量用 v_。这个习惯一旦养成，看别人代码时能省掉大量“这个值是外面传进来的还是过程内计算出来的”提问。
4. 开始加逻辑：IF、CASE和变量处理的三个高频坑
4.1 变量声明位置、赋值时机这些规则先理清
存储过程“上”这个阶段，一般会先讲到变量。变量不是SQL的天然概念，SQL里不存在“这次查询的值等一下再复用”这种说法。但PL/SQL这类过程化SQL存在。
Oracle的变量声明位置是 IS 之后、BEGIN 之前，集中声明，不允许在语句块中间临时又冒出一个变量。MySQL稍稍灵活一些，但也建议把所有变量集中在 BEGIN 开头统一声明，可读性和结构化程度都会明显更好。
给变量赋值，Oracle用 :=，MySQL用 SET 或 SELECT INTO。SQL Server用 SET @变量 = 值 或 SELECT @变量 = 列 FROM ...。这里经常出现的坑是：如果你在Oracle里写 SELECT COUNT(*) INTO v_count FROM employees;，查询结果必须是单行单列，否则会直接抛 TOO_MANY_ROWS 或 NO_DATA_FOUND 异常，而且这两个默认不会被上层源码捕获，会把整个过程停止。所以带 SELECT INTO 的语句，最好心里有数“它最多只返回一行”。
4.2 IF判断的数据库语文差异：ELSIF不是ELSEIF
写条件分支时最容易写错的是 ELSIF。这个关键字在Oracle和MySQL里都叫 ELSIF，少写一个字母，就是二合一。SQL Server则完全是另一套写法，没有 IF ... ELSIF，它的分支结构是 IF ... ELSE IF ... ELSE。
Oracle的IF完整写法是：
oracle复制IF v_type = 1 THEN
v_msg := '类型一';
ELSIF v_type = 2 THEN
v_msg := '类型二';
ELSE
v_msg := '其他';
END IF;
注意最后是 END IF;，两个单词之间有一个空格。很多新手写成了 ENDIF，这个在Oracle里会直接编译报错；如果前面还有个 IF 忘了闭合，报错位置还会跑到过程的最后一行，特别让人抓狂。
当判断条件比较多、且每一项都在比较同一个字段时，用 CASE 会比 IF 链更清晰。在PL/SQL里它既可以在SQL语句里用，也可以直接在过程里赋值：
oracle复制v_msg := CASE v_type
WHEN 1 THEN '类型一'
WHEN 2 THEN '类型二'
ELSE '其他'
END;
这里的 END 后面有没有分号取决于它在赋值语句中的位置。如果你从 CASE 表达式里漏了 END，报错信息往往不会直接指向CASE，而会指向下一行，这种“错误行号差一”的经验非常磨人。
4.3 字符串转义和单引号问题：Oracle和MySQL的规则不一样
这个坑在真实开发中几乎每个写过程的人都会踩。你在Oracle存储过程里拼动态SQL，或者往表里插入一段包含单引号的字符串，就会遇到引号转义问题。
Oracle字符串字面量用单引号表示，字符串内部的单引号要写两个单引号来转义。比如你想让变量 v_sql 变成 SELECT * FROM emp WHERE name='张三'，你不能直接写成：
oracle复制v_sql := 'SELECT * FROM emp WHERE name='张三'';
这样写会编译失败，因为Oracle读到第一个单引号和第二个单引号之间就已经结束了字符串。正确写法是把需要保留的那个单引号重复一次：
oracle复制v_sql := 'SELECT * FROM emp WHERE name=''张三''';
如果SQL里还涉及到变量值拼接，整个引号套娃很容易让人头晕。所以我从某次踩坑之后总结了一套做法：优先让动态SQL里的字符串变量不要去手动拼，能用绑定变量的地方就用绑定变量。如果非拼不可，可以用Oracle的 q 引号语法，把默认的单引号定界符换成其他字符：
oracle复制v_sql := q'[SELECT * FROM emp WHERE name='张三']';
在MySQL存储过程里，单引号处理和标准SQL类似，主字符串用单引号，内部单引号写成两个也可以，也可以借助双引号作为字符串定界符——但注意不要和 sql_mode 里允许双引号作为字符串引号的设置冲突。实际操作时最好统一规范：代码里的字符串一律单引号，动态SQL里的引号嵌套则尽量通过参数化或函数处理，避免可读性崩坏。
5. 从“建好”到“能查、能调、能排错”：执行计划与调试方法论
5.1 存储过程也是SQL，执行计划不要只看内部单条语句
有时候创建过程没有报错，调用结果也是对的，可用户反馈页面越来越慢。这时候很多人第一反应是“是不是索引没建好”，但问题可能藏在过程里某条 UPDATE、DELETE 或大表关联上。怎么定位？不同数据库有不同工具，但思路完全一致：把过程内每一条独立SQL的执行计划单独拉出来看。
Oracle方面，你可以直接对过程做查询，也可以在存储过程中对某条SQL执行 EXPLAIN PLAN FOR，再查 DBMS_XPLAN.DISPLAY。但更精细的思路是打开 DBMS_PROFILER 或看 V$SQL 历史，找到过程执行时内部实际消耗比例最大的那几条SQL，然后针对那几条语句做 EXPLAIN PLAN。
MySQL可以用 EXPLAIN SELECT...，但如果过程里是UPDATE，光看单条语句有时不够，还要配合 SHOW PROFILE 或开启慢日志。SQL Server里常见的做法是 SET STATISTICS IO ON; SET STATISTICS TIME ON; 或直接看图形化执行计划。DM（达梦）数据库自带的管理工具里也可以直接查看某个存储过程的执行计划：一般是在SQL编辑器里先执行存储过程，之后在工具栏或会话窗口找到“执行计划”功能，或者通过查询动态视图 V$SQL_PLAN 之类的系统视图查看刚刚执行过SQL的计划。
大多数人下意识犯的错是：因为过程慢，就把整段逻辑搬出来在工具里跑一遍，再试图从整块输出里找慢点。正确姿势是拆，把过程的内部语句拆出来单测，尤其是看过滤条件的基数估算。一个过程里如果有2条大SQL，其中1条1毫秒，另1条1秒，你把整段过程执行计划打出来是看不出这1秒在哪里的。
5.2 C#、Java或命令行中的OUT参数看不到结果？多半是提交问题
很多时候“过程没出结果”并不是过程写法有问题，而是程序调用时没把输出参数接住。C#执行MySQL存储过程的坑我在前面已经写过一个 CommandType 问题，其实还有一个更容易犯的：写入了OUT参数但未设置长度或调用了 ExecuteNonQuery 之后没有立即读取，而是在连接关闭后才去读参数集合，此时参数值已经被清空。
Oracle的JDBC场景也一样。用 CallableStatement 注册输出参数之后，要等 execute() 返回再读取结果。如果过程前边执行了 COMMIT 或抛了异常，未提交数据回滚，这些也会影响你看到的结果。这是典型的“过程本身没有问题，但调用姿势有问题”。
5.3 简单调试三板斧：打印、日志表和异常捕获
Oracle下最直接的做法是打开 DBMS_OUTPUT，再在过程内用 DBMS_OUTPUT.PUT_LINE 打印中间变量。这个输出只能由客户端读取，而且默认容量有限，不适合打印超长对象。MySQL没有原生内置那样的 PUT_LINE，你有几种替代方式：
- 把调试信息INSERT到一张临时日志表；
- 用
SELECT 提示信息;当结果集返回； - 在程序端把
out参数值打出来看。
真正在线上环境调试，我偏向写一张 procedure_run_log 表，插入关键节点和变量值。排障时可以直接查这个表，不用依赖客户端是否开启输出。日志表建议包含这些字段：日志ID、过程名、执行时间、级别、业务主键、说明。这样即使过程在半夜被定时任务触发，你第二天来也有完整日志可回溯，不会因为错过了输出窗口而抓瞎。
另外要强调的是过程内的 EXCEPTION 块。刚开始写过程的人几乎不会主动加异常处理，直到某天过程在夜里跑挂而你找不到任何痕迹。高级别习惯是：入口统一加一个兜底异常，捕获之后记录错误信息并重新抛出或转换业务错误码。这次“上”的段落先不展开 WHEN OTHERS 的细节，但至少现在就要知道：把异常默认让数据库报出来，等于放弃了定位一条复杂过程故障的第一手线索。
6. 命名约定、定时执行与实战中的最小可运行模板
6.1 系统开发中存储过程命名规则到底怎么定才合理
如果你负责维护的系统里出现过 proc_a, pr_001, sp_getuser_2020, UP_Login_Ver1 这一堆名字并列，你应该能理解为什么要有命名规范。命名不统一，最痛的不是约束力不够，而是当系统出故障时，你看见一个叫 pr_getdata 的过程根本不知道它是干嘛的，得点开代码才明白。
我见过几套常用的规范，行业里比较常见的是按模块前缀、业务动作和对象类型组合：
SP_或P_开头，表示存储过程；- 后面跟业务模块或对象名，比如
ORDER、ACCOUNT、USER； - 再跟动作，比如
CREATE、UPDATE、BATCH。
例如 SP_ORDER_AUTO_CLOSE，表示订单模块的自动关闭过程。Oracle里很多老系统则习惯直接用过程名表达业务意图，比如 proc_close_overdue_order。这倒不是强要求，关键是团队内部要一套统一标准，并且要让过程名出现在数据库字典或日志里时能很快反查业务模块。
需要额外提示的是：存储过程属于数据库对象，重命名成本往往比改名一个函数高，因为依赖它的作业、程序代码、报表可能都得跟着改动。所以命名决策一定要在代码评审阶段做，而不是上线后再纠结。
6.2 定时执行存储过程的几种常规姿势
业务系统里很多存储过程都会被设成定时任务来跑，比如每天凌晨统计前一天数据、每5分钟刷新一次订单状态。这里不同数据库的定时方案差异非常大：
- Oracle：使用
DBMS_SCHEDULER或老的DBMS_JOB。DBMS_JOB简单但功能弱，推荐优先使用Scheduler。创建定时任务的经典写法是：
oracle复制BEGIN
DBMS_SCHEDULER.CREATE_JOB (
job_name => 'JOB_CLOSE_OVERDUE_ORDER',
job_type => 'STORED_PROCEDURE',
job_action => 'SP_ORDER_AUTO_CLOSE',
start_date => SYSTIMESTAMP,
repeat_interval => 'FREQ=HOURLY; INTERVAL=1',
enabled => TRUE
);
END;
创建完成后可通过 DBMS_SCHEDULER.DROP_JOB 删除，通过 DBA_SCHEDULER_JOBS 查看。
- MySQL：使用
EVENT。需要先开启调度器event_scheduler=ON，再创建事件，比如让存储过程每天凌晨2点执行一次：
mysql复制CREATE EVENT IF NOT EXISTS ev_close_overdue_order
ON SCHEDULE EVERY 1 DAY
STARTS '2025-01-01 02:00:00'
DO
CALL SP_ORDER_AUTO_CLOSE();
MySQL的事件和管理工具配合起来很顺手。它不像Oracle那样区分job和scheduler，所以理解起来更直接。
- SQL Server：使用SQL Server Agent下的Job，里面可以指定一个步骤执行
EXEC SP_ORDER_AUTO_CLOSE，再设置计划。
这里几乎每个库的踩坑姿势都不同，但有一条通用规则：定时任务本身不要包装太复杂。Job生效的第一步不是看过程有没有被正常创建，而是查调度器的状态和执行日志。Oracle要看 DBA_SCHEDULER_JOB_RUN_DETAILS，MySQL要看 information_schema.events 和慢日志。如果过程执行失败，你却只看Job有没有触发，容易忽略真正的问题。
6.3 “上半场”的小模板：一个完整的可复用示例
最后，我放一个综合了变量、参数和分支控制的小过程，可以直接在Oracle库体验完整逻辑，也可以映射成你熟悉库的语法。
需求是这样的：传入一个订单号，如果订单状态为待支付且超时超过30分钟，把它改成已取消并返回状态码1；如果订单不存在，返回-1；其他状态直接返回0。
oracle复制CREATE OR REPLACE PROCEDURE sp_order_auto_cancel(
p_order_id IN orders.order_id%TYPE,
p_status OUT NUMBER
) IS
v_stat orders.status%TYPE;
v_create_dt orders.create_time%TYPE;
BEGIN
SELECT status, create_time
INTO v_stat, v_create_dt
FROM orders
WHERE order_id = p_order_id;
IF v_stat = 'PENDING' AND v_create_dt < SYSTIMESTAMP - INTERVAL '30' MINUTE THEN
UPDATE orders SET status = 'CANCELLED' WHERE order_id = p_order_id;
p_status := 1;
ELSE
p_status := 0;
END IF;
EXCEPTION
WHEN NO_DATA_FOUND THEN
p_status := -1;
END sp_order_auto_cancel;
这段里用了 orders.order_id%TYPE，它能把参数的声明跟表字段类型绑定，表结构一改，过程参数类型也会跟着适配。使用 %TYPE 属性在大型项目里能减少很多“参数长度不够导致隐式转换”的维护问题。
过程本身完成的是：根据订单创建时间自动超时取消。这里也顺带展示了一个关键点——异常处理把“订单不存在”从一次错误变成一次正常返回，这是存储过程被大量用于系统对接时很常见的惯用法。
“上”篇收笔时我建议你亲自做一遍的事
如果现在让你打开数据库，亲手完成下面这五件事，你基本就能把“存储过程上”掌握到能上手项目的程度：
- 建一张简单的测试表，插入几行数据；
- 用
CREATE OR REPLACE PROCEDURE写一个带IN参数和OUT参数的过程； - 在过程中使用IF判断并给OUT参数赋值；
- 调用过程并打印OUT参数；
- 故意写一个指向不存在记录的查询，观察
NO_DATA_FOUND异常如何让过程中断。
这个过程如果你只看了没动手，大概率三天后就忘。我见过太多同学在理论上能把各种语法背得滚瓜烂熟，一进真实库就忘了 :=、ELSIF、END IF 这些关键字，因为它们太碎了。只有亲手编译过几次、报过错几回，才能把这块经验焊在脑子里。等这段地基打牢，“存储过程下”的循环、游标、动态SQL和复杂异常处理才有地方展开。