企业官网建设流程全解析

1. 存储过程过时了吗：我在真实业务里重新审视它的价值

这两年聊到这个话题，很多做后端开发的同事第一反应是：存储过程不是老古董吗？现在都流行ORM、微服务，业务逻辑不都写在应用层吗？说实话，我在早期也是这么想的，直到有一次接手一个库存和订单联动的模块，才重新开始正视存储过程在MySQL里的价值。

先说结论：存储过程并没有过时，它只是更挑场景了。在复杂的多表事务、批量数据处理、需要严格保证原子性的业务里，把一段逻辑直接塞进数据库里执行，能省掉大量的应用层与数据库之间的网络往返。如果你一个操作需要执行七八条SQL，并且中间有判断、循环和异常回滚，用存储过程明显比在应用层拼SQL再逐条发送高效得多。

这篇文章我会围绕MySQL存储过程，从基础语法讲到设计思路，再讲到我实际踩过的坑和排查方法。适合两类人看：一类是刚接触存储过程、想系统搞懂它怎么用的小白；另一类是写过几个存储过程但在复杂业务里总觉得"哪里不对劲"的开发者。我会尽量把能直接抄的模板和不能踩的雷区分开，让你读完就能上手改你自己的需求。

2. 从无到有搭一个最简存储过程：语法骨架和参数逻辑

2.1 标准的CREATE PROCEDURE写法

先看一个最基础的示例，这个结构几乎是所有存储过程的骨架：

DELIMITER $$ CREATE PROCEDURE sp_hello_world(IN p_name VARCHAR(50), OUT p_result VARCHAR(100)) BEGIN SET p_result = CONCAT('Hello, ', p_name); END$$ DELIMITER ;

这里有几个细节第一次接触的人很容易懵。

DELIMITER到底在干嘛？MySQL默认用分号作为语句分隔符，可存储过程内部本身就有大量分号结束的语句。如果不临时把分隔符改成$$，MySQL会在你写完SET语句时误以为整个CREATE PROCEDURE已经结束，然后报语法错误。所以DELIMITER $$的意思是："从这行开始，我用$$当结束标志，直到DELIMITER ;改回来。"

再来看参数的三类模式，这个理解透了基本就懂了一大半：

举个例子，如果我想返回一个业务状态码和提示信息，用OUT参数就很舒服：

DELIMITER $$ CREATE PROCEDURE sp_check_user_status(IN p_user_id INT, OUT p_code INT, OUT p_msg VARCHAR(100)) BEGIN DECLARE v_cnt INT DEFAULT 0; SELECT COUNT(*) INTO v_cnt FROM t_user WHERE user_id = p_user_id; IF v_cnt = 0 THEN SET p_code = 404; SET p_msg = '用户不存在'; ELSE SET p_code = 200; SET p_msg = '用户正常'; END IF; END$$ DELIMITER ;

调用的时候这样写：

CALL sp_check_user_status(1001, @code, @msg); SELECT @code, @msg;

用户变量@code、@msg不需要事先声明，CALL执行完直接SELECT就能看到结果，在应用层里用SELECT @code, @msg取回来非常方便。

2.2 查询和管理存储过程的基本命令

代码写完了总得验证，有几个命令是日常维护里我几乎每天都要用的：

-- 查看所有存储过程 SHOW PROCEDURE STATUS WHERE Db = '你的数据库名'; -- 查看某个存储过程的创建语句 SHOW CREATE PROCEDURE sp_hello_world; -- 从information_schema查看更详细的信息 SELECT * FROM information_schema.ROUTINES WHERE ROUTINE_SCHEMA = '你的数据库名' AND ROUTINE_NAME = 'sp_hello_world';

我特别推荐最后一种查询方式，因为ROUTINES表里除了定义语句，还包含了CREATED、LAST_ALTERED、DEFINER这些字段。有一次线上某个存储过程被人改过但没同步文档，我就是靠LAST_ALTERED定位到修改时间的。

删除和修改也比较直接：DROP PROCEDURE IF EXISTS sp_xxx;用于删除，ALTER PROCEDURE虽然存在但MySQL对它的支持有限，实际开发里我基本不用ALTER，而是直接DROP再重新CREATE。因为存储过程的依赖通常很简单，重建的开销远低于在旧版本上打补丁。这个习惯在多人协作时特别重要：每次变更都重建，配合版本控制里的SQL脚本文件，能清楚看到每次改动差异。

3. 变量、流程控制、游标与异常处理：存储过程的核心驱动力

3.1 DECLARE声明变量与SELECT INTO赋值的坑

存储过程内部用的变量必须先用DECLARE声明，这点和普通SQL完全不一样。声明的位置也有讲究，必须在BEGIN之后、任何其他语句之前。我见过不少人把DECLARE写在SET语句后面，直接报"DECLARE is only allowed at the start of a BEGIN...END block"的错误。

DECLARE v_cnt INT DEFAULT 0; DECLARE v_total DECIMAL(10,2) DEFAULT 0.00; DECLARE v_status TINYINT DEFAULT 0;

变量赋值有两种方式：SET v_cnt = 1;用于直接赋固定值；SELECT COUNT(*) INTO v_cnt FROM t_order WHERE ...;用于把查询结果赋给变量。

这里有个高频坑：如果SELECT INTO的查询返回了多行，MySQL会报警告并只取第一行；如果返回零行，变量值不会变，仍然保留之前的默认值。很多bug就是这样潜伏下来的——你查了一个不存在的订单，原本期望v_cnt是0，但因为变量之前被赋过值，实际上拿到的是旧值。所以我习惯在SELECT INTO之前先把变量重置一次：

SET v_cnt = 0; SELECT COUNT(*) INTO v_cnt FROM t_order WHERE order_id = p_order_id;

至于为什么推荐用COUNT(*)而不是去取某个字段再判断是否为NULL，是因为COUNT即使查不到数据也返回0，不会产生"变量值未更新"的困惑。

3.2 IF、CASE、WHILE、LOOP的实际组合套路

流程控制语法本身不难，难在什么时候用哪个。这里给一套基于实际场景的选择逻辑。

IF适合分支条件较少的情况，比如判断状态码是200还是404：

IF v_cnt = 0 THEN SET p_code = 404; ELSEIF v_cnt > 10 THEN SET p_code = 429; ELSE SET p_code = 200; END IF;

注意MySQL的写法是ELSEIF，连在一起没有空格，这点和其他语言习惯有差异。

CASE适合多条件等值判断。比如订单状态有10个取值，你想翻译成中文描述：

CASE p_order_status WHEN 1 THEN SET v_desc = '待支付'; WHEN 2 THEN SET v_desc = '已支付'; WHEN 3 THEN SET v_desc = '已发货'; ELSE SET v_desc = '未知状态'; END CASE;

WHILE和LOOP做循环时，我推荐按需选用。如果循环次数明确就用WHILE：

WHILE v_i < v_total DO -- 处理逻辑 SET v_i = v_i + 1; END WHILE;

如果需要在循环体内部根据条件提前退出，用LOOP更灵活：

SET v_i = 0; loop_label: LOOP SET v_i = v_i + 1; IF v_i >= 10 THEN LEAVE loop_label; END IF; END LOOP;

LEAVE相当于其他语言里的break，ITERATE相当于continue。这两个关键字和loop_label标签配合使用，能写出非常清晰的循环控制逻辑。不过说句大实话，存储过程里尽量别写特别复杂的嵌套循环，不仅调试麻烦，而且执行效率容易出问题。复杂逻辑拆成多个简单存储过程，或者用临时表过渡，往往更舒服。

3.3 游标：逐行处理时的双刃剑

游标是存储过程让我又爱又恨的一部分。爱的是，确实有些场景逐行处理最直观；恨的是，性能差、写法繁琐、稍不注意就出bug。

标准的游标使用流程是一个固定五步：

DECLARE v_done INT DEFAULT 0; DECLARE v_id INT; DECLARE cur CURSOR FOR SELECT id FROM t_user WHERE status = 1; DECLARE CONTINUE HANDLER FOR NOT FOUND SET v_done = 1; OPEN cur; read_loop: LOOP FETCH cur INTO v_id; IF v_done = 1 THEN LEAVE read_loop; END IF; -- 对v_id做处理 END LOOP; CLOSE cur;

这段代码里最关键的是那个CONTINUE HANDLER FOR NOT FOUND SET v_done = 1;。游标读取到尾部的标志就是NOT FOUND，而MySQL没有直接在FETCH语句里返回"没有更多数据"的能力，必须靠这个Handler去捕获。这个Handler的声明位置必须放在游标声明之后，放在其它地方可能会作用不到当前游标上。

第二个常见问题是游标必须用完就CLOSE。有些人写了循环但忘了关闭游标，在存储过程持续执行的场景里连接资源会逐渐耗尽，最终报"Cursor is not open"或者连接数爆满。

第三个性能问题是：游标嵌套循环极其容易产生N+1查询，数据库每FETCH一次就执行一次内部SQL，数据量一大慢得怀疑人生。我建议但凡遇到游标加子查询的场景，先想想能不能一次性用JOIN取全量数据放到临时表，再用一个更简单的游标去处理。

3.4 异常处理：DECLARE EXIT HANDLER让事务不再裸奔

存储过程里最容易被忽略的就是异常处理。MySQL默认情况下，某条SQL语句报错会导致整个存储过程立即报错退出，但不会自动回滚你的未提交事务。如果你在过程中已经做了INSERT/UPDATE操作，又没有显式处理异常，那出错的瞬间那些未提交的修改就悬在那里，连接关闭后被回滚，过程内没来得及执行的代码全部作废。

正确的打开方式是在BEGIN块的开头声明Handler：

DECLARE EXIT HANDLER FOR SQLEXCEPTION BEGIN ROLLBACK; RESIGNAL; END;

这段代码的意思是：只要遇到任何SQL异常，立刻进入Handler，先回滚事务，然后用RESIGNAL重新抛出原始错误信息。这样做的好处是，应用层拿到的错误还是真实的数据库错误，不是被吞掉的假消息。

如果你需要区分不同类型的错误，可以用错误码：

DECLARE EXIT HANDLER FOR SQLSTATE '23000' BEGIN -- 唯一键冲突、外键约束失败等 SET p_code = 50001; ROLLBACK; END;

SQLSTATE '23000'涵盖了一类约束违反错误，这在插入重复主键、违反唯一索引时特别适用。我是强烈建议业务型存储过程都至少加一个兜底的SQLEXCEPTIONhandler，否则上线以后出了问题，排查起来真的像大海捞针。

4. 实战：一个库存扣减与订单创建的完整存储过程

4.1 需求拆解与事务边界设计

现在来看一个实际项目里很有代表性的案例：用户下单时，要同时更新商品库存、创建订单、写一条订单流水。这个场景特别适合存储过程，因为多张表的一致性要求非常高，而且操作顺序固定。

需求拆解后包含以下几步：

1. 校验用户是否存在且状态正常
2. 校验商品是否存在且上架
3. 检查库存是否充足
4. 扣减库存
5. 创建订单
6. 写入订单流水
7. 事务提交

事务边界怎么划？我建议从第一步一直到最后一步全部放在同一个事务里。因为中间任何一步失败，比如库存不足，都不应该留下"用户已下单但商品被锁定"这样的半成品数据。

4.2 带注释的完整可运行示例

DELIMITER $$ CREATE PROCEDURE sp_create_order( IN p_user_id INT, IN p_goods_id INT, IN p_quantity INT, OUT p_order_id BIGINT, OUT p_code INT, OUT p_msg VARCHAR(100) ) BEGIN DECLARE v_stock INT DEFAULT 0; DECLARE v_price DECIMAL(10,2) DEFAULT 0; DECLARE v_user_status TINYINT DEFAULT 0; DECLARE v_goods_status TINYINT DEFAULT 0; DECLARE EXIT HANDLER FOR SQLEXCEPTION BEGIN ROLLBACK; SET p_code = 500; SET p_msg = '系统异常，事务已回滚'; END; START TRANSACTION; -- 1. 校验用户 SELECT status INTO v_user_status FROM t_user WHERE user_id = p_user_id FOR UPDATE; IF v_user_status != 1 THEN SET p_code = 40001; SET p_msg = '用户状态异常'; ROLLBACK; LEAVE proc_exit; END IF; -- 2. 校验商品并锁行 SELECT stock, goods_status, price INTO v_stock, v_goods_status, v_price FROM t_goods WHERE goods_id = p_goods_id FOR UPDATE; IF v_goods_status != 1 THEN SET p_code = 40002; SET p_msg = '商品已下架'; ROLLBACK; LEAVE proc_exit; END IF; -- 3. 库存判断 IF v_stock < p_quantity THEN SET p_code = 40003; SET p_msg = '库存不足'; ROLLBACK; LEAVE proc_exit; END IF; -- 4. 扣减库存 UPDATE t_goods SET stock = stock - p_quantity WHERE goods_id = p_goods_id; -- 5. 创建订单 INSERT INTO t_order(user_id, goods_id, quantity, amount, create_time) VALUES(p_user_id, p_goods_id, p_quantity, p_quantity * v_price, NOW()); SET p_order_id = LAST_INSERT_ID(); -- 6. 写订单流水 INSERT INTO t_order_log(order_id, operate_type, operate_desc, create_time) VALUES(p_order_id, 'CREATE', '用户下单', NOW()); COMMIT; SET p_code = 200; SET p_msg = '下单成功'; END$$

4.3 关键设计点说明

这段代码里有几个细节很重要，值得单独说清楚。

为什么用SELECT ... FOR UPDATE？因为在高并发情况下，如果直接用SELECT查库存再UPDATE，两个请求可能同时读到同一个库存值，最终导致超卖。FOR UPDATE会对查询的行加写锁，第二个事务必须等第一个事务提交或回滚后才能继续读这行。这也是存储过程在库存类业务里比应用层多条SQL更有优势的原因之一——锁的范围小，持续时间短，但足够保护关键数据。

变量名容易踩的典型坑：这段例子里我特意把v_stock、v_price命名为v_开头的变量名，是为了和列名区分开。如果你写SELECT stock INTO stock FROM t_goods WHERE ...，MySQL有时会产生歧义，导致变量赋值失败或行为怪异。我见过团队里有人因为变量名和列名完全一致，结果SELECT stock INTO stock更新的一直是列值而不是变量，排查了两天才发现。

LEAVE proc_exit的用法：这段例子里我直接用了LEAVE proc_exit想提前跳出过程，但你需要先声明一个proc_exit:标签。如果忘记声明直接写LEAVE proc_exit，会直接语法报错。更稳妥的做法是在每个失败的IF逻辑里直接ROLLBACK并SET p_code，然后在IF外面统一用IF p_code != 200 THEN RETURN; END IF;来控制退出，避免标签管理带来的额外负担。

为什么先ROLLBACK再SET返回参数：在异常Handler里，如果先设返回参数再ROLLBACK，事务回滚本身也可能抛出异常，导致返回参数被覆盖掉。所以我调整了顺序，先回滚，再设参数，更可靠。这一点在实际运行环境中虽然概率低，但值得养成习惯。

4.4 应用层调用的配套写法

在Java侧配合MyBatis使用了一个常见的坑：MySQL默认每个存储过程的调用是独立事务，但应用层连接如果开启了事务，可能会影响存储过程内部的事务控制。因此我建议调用存储过程时，应用层不要包一层大事务，让数据库自己管提交回滚。

// 伪代码示例 Map<String, Object> params = new HashMap<>(); params.put("p_user_id", userId); params.put("p_goods_id", goodsId); params.put("p_quantity", 2); // OUT参数需要提前注册 procMapper.createOrder(params); Integer code = (Integer) params.get("p_code"); String msg = (String) params.get("p_msg");

如果用的是MyBatis注解方式，记得在映射语句里加statementType="CALLABLE"，否则MyBatis不知道你调用的是存储过程。

5. 存储过程设计与调优：几个容易翻车的细节

5.1 事务里不要做无用功

存储过程一旦进入START TRANSACTION，所有操作持有的锁要一直保持到COMMIT或ROLLBACK。所以在事务里做冗长的日志拼接、字符串处理、发邮件、调外部接口，都是非常不理智的。锁被拖延的时间越长，其他会话等待的概率越大，极端情况下形成锁等待超时。

我见过一个失败案例：存储过程里插入订单后，又用循环去逐个更新一张关联表的十几个字段，表面上看逻辑很清晰，但实际执行下来在并发场景里大量出现Lock wait timeout exceeded。后来改成一次UPDATE ... WHERE ... IN (...),速度提升了一倍不止，锁时间也大幅缩短。

所以说，存储过程里能用一条SQL完成的，绝对不用循环；能先算完再写库的，绝不在事务中间穿插其他操作。

5.2 动态SQL到底该不该用

动态SQL（PREPARE、EXECUTE）在存储过程里可以构造灵活的条件查询，但它也有明显的代价：动态SQL基本无法避免SQL注入风险，而且MySQL没法对它做语句缓存优化。我的原则是：能用静态SQL表达的需求，就不要用动态SQL；只有表名、列名确实必须动态切换的极端场景才考虑。

如果必须用，至少用?占位符绑定参数，不要直接拼接字符串：

SET @sql = 'SELECT * FROM t_order WHERE user_id = ?'; PREPARE stmt FROM @sql; SET @user_id = 10086; EXECUTE stmt USING @user_id; DEALLOCATE PREPARE stmt;

5.3 临时表的开启与生命周期管理

有些复杂的报表统计类存储过程，需要先汇总中间结果再进一步处理。MySQL里临时表默认也是可以在存储过程内创建使用的，但要注意临时表占用的内存、磁盘空间与连接会话绑定。存储过程执行结束、连接关闭，临时表自动销毁，这个特性用好了很舒服，用不好容易把临时表空间撑爆。

建议在创建临时表时给关键字段建索引，尤其是后续要按这些字段做JOIN和WHERE过滤的字段。否则数据量大一点，临时表上的全表扫描会拖垮整个存储过程：

CREATE TEMPORARY TABLE tmp_order_stat ( user_id INT NOT NULL, order_cnt INT NOT NULL, total_amount DECIMAL(10,2) NOT NULL, KEY idx_user_id (user_id) ) ENGINE = MEMORY;

注意，ENGINE = MEMORY适合数据量不大的场景，如果统计结果行数超过内存配置，会直接报错。稳妥起见，数据量大的场景用默认的临时表引擎更安全。

5.4 存储过程性能调优的关注维度

参数调优时，主要关注几个维度：

调优思路和应用层SQL基本一样，先定位慢SQL，再看执行计划，最后决定加索引还是改逻辑。不同的是，存储过程里多个SQL串行执行，每一环都可能成为瓶颈，所以定位到具体哪条SQL是第一步，绝不能只盯着整段过程看平均耗时。

6. 排查与维护：存储过程出问题时怎么快速定位

6.1 慢在哪一步：给每个关键节点加诊断型输出

存储过程不像是应用层代码，你没法直接打断点。我最常用的调试手段是在关键节点写诊断日志。MySQL里没有内置的print函数，但可以往一张日志表插入进度信息。

CREATE TABLE proc_debug_log ( id BIGINT AUTO_INCREMENT PRIMARY KEY, proc_name VARCHAR(100), step_desc VARCHAR(255), affect_rows INT, extra_msg VARCHAR(500), create_time DATETIME );

在存储过程的关键步骤间隙插入日志：

INSERT INTO proc_debug_log(proc_name, step_desc, affect_rows, extra_msg, create_time) VALUES('sp_create_order', '库存扣减完成', ROW_COUNT(), CONCAT('order_id=', p_order_id), NOW());

ROW_COUNT()能拿到上一条DML语句影响的行数，这个信息在排查"为什么没更新成功"时特别有用。执行完存储过程后，查一下这个日志表，就能还原出整个过程走到哪一步、哪一步影响了几条数据。

6.2 用日志定位慢SQL和异常错误

如果存储过程跑得慢，靠整体计时没意义，必须知道时间花在哪里。有两个方式：

第一个是利用performance_schema的events_statements_summary_by_digest。开启相关采集项后，所有执行的SQL语句都会按digest_text聚合，你能看到总耗时、平均耗时、扫描行数，一眼就能看出哪条SQL是瓶颈。

第二个更朴素一点，在存储过程的每个大步骤前后记录时间戳，存进日志表。比如扣减库存之前记录NOW()，扣减之后再记录一次，两段日志之间的时间差就是该步骤的耗时。这个方法虽然粗糙，但在没有工具权限的环境里非常实用。

6.3 版本管理和多人协作的规范

存储过程的版本管理一直是个痛点，因为它在数据库里直接运行，没有Git可以diff。我在团队里推行了一套具体做法，效果还不错：

• 每个存储过程单独一个SQL脚本文件，命名规范为日期_作者_过程名.sql，放在专门的db目录里纳入版本控制
• 脚本文件头部统一写清创建人、修改人、修改目的、影响范围
• 线上变更前，先把脚本在测试库执行并通过验证，再走发布窗口执行
• 发布时记录一个版本号到专门的版本表里，方便回滚时对照

CREATE TABLE db_release_log ( version_no VARCHAR(20), proc_name VARCHAR(100), change_desc VARCHAR(500), operator VARCHAR(50), release_time DATETIME );

这套规范的最大价值在于：当新同事接手老代码时，不用靠问来还原某个存储过程为什么存在、为什么这么写。脚本里的注释能回答大部分问题，版本表能告诉你上一次改动是在什么背景下做的。

6.4 线上存储过程维护的几个禁忌

最后列几个我踩过坑之后记住的禁忌，全部来自真实教训：

• 不要在业务高峰期直接DROP再CREATE一个频繁调用的存储过程。重建期间，所有调用该存储过程的请求都会直接报错。宁可提前在低峰期或通过版本控制里的脚本变更。
• 不要用DEFINER指定已经不存在的账号。存储过程创建后，调用时MySQL会校验DEFINER权限，如果创建账号被删除，即使你有权限也会报错。写过一次这类问题后，我创建前都会确认当前登录账号的口令。
• 不要过分依赖存储过程去处理所有业务逻辑。存储过程中调试、监控、测试的成本都比应用层高，只适合放需要严格一致性的核心事务。我见过一个项目把十几条业务规则全塞进一个几十行为的存储过程，后来改需求时改一次崩一次，最终重构时拆成了应用层逻辑加少量存储过程，大家才喘过气。

7. 使用存储过程时最容易忽略的权限与执行安全问题

权限这块平时容易被忽略，但对线上系统的稳定性和安全性影响很大。MySQL里存储过程有两个和权限相关的核心机制：DEFINER和SQL SECURITY。

DEFINER是定义者，指创建这个存储过程的账号；SQL SECURITY则控制调用者以谁的权限执行。默认值是DEFINER，也就是任何能调用这个存储过程的账号，都会以创建者的权限去执行过程内的SQL。这带来一个隐藏风险：如果你用一个超级管理员账号创建了存储过程，然后给了普通业务账号EXECUTE权限，那么普通账号虽然不能直接SELECT表数据，但通过调用这个存储过程，实际能读到这些表里的内容——因为底层SQL是以管理员权限执行的。

我在实际运维里见过一次事故：某个存储过程本意是让运营同事查询订单汇总，但因为创建账号权限过大，所有调用者都能通过这个存储过程读取订单明细里的用户手机号。解决方式很简单：第一，创建存储过程时尽量用最小权限账号；第二，设置SQL SECURITY INVOKER，让执行者以自己的权限运行，SQL越权自然就会被拦截。

CREATE DEFINER='low_priv_user'@'%' SQL SECURITY INVOKER PROCEDURE sp_query_summary() BEGIN -- 查询逻辑 END

同时，权限申请的审批流程也不能省。每建一个存储过程，都要确认究竟谁会调用它、调用时需要哪些表权限、该给哪些账号授予EXECUTE权限。执行权限精确到账号，不要图省事给所有人开绿灯。

8. 从维护和拆分的角度看存储过程的使用边界

聊完技术细节，最后说说更宏观的使用边界判断。很多人问过我：什么样的业务适合用存储过程，什么样的不适合？我自己的判断标准一直在动态调整，目前比较明确的倾向如下。

适合用存储过程的

• 库存扣减、金额变动、订单状态流转这类必须保证原子性的核心写操作
• 批量初始化数据、备份归档、定时任务里的复杂调度逻辑
• 报表统计中间层的多表聚合计算（如果数据量可控且不要求实时）

不适合用存储过程的

• 需要频繁变动业务规则的场景。改应用代码一行比改存储过程安全得多，还能走代码审查流程
• 复杂的报表查询和数据透视。这类场景应该借助对应的查询引擎或OLAP平台，而不是在OLTP数据库里硬算
• 依赖大量外部服务调用的逻辑。存储过程里没法方便地发HTTP请求，硬做很别扭

如果两者边界重叠，我更倾向于拆分：核心事务放数据库里做，非核心的衍生逻辑放应用层做。比如生成订单这件事，扣库存、写订单、写流水可以捆在一个存储过程里，但发送通知、更新推荐位缓存、同步搜索索引这些实时性要求没那么高的，放在应用层通过队列异步处理就好。

这样拆完以后，存储过程保持小巧、单一、稳定，应用层逻辑又不会因为事务太大拖垮性能。我参与过的一个订单系统重构项目就是这么做的，存储过程从原来几十个缩减到只有八个核心事务，反而线上稳定性提升了一大截，排查问题的速度也快了很多。所以说，存储过程本身不背"难维护"的锅，设计边界模糊才是根源。

每次我在新的项目里讨论技术选型，都会把存储过程放进候选里再认真权衡。它算不上一刀切的银弹，也确实有自己独特的位置。如果你正在做涉及高一致性事务的系统，建议多花一点时间把存储过程这门基本功打扎实，后面遇到复杂的并发和补偿场景，你会感谢自己此刻的认真。