MySQL存储过程实战指南：游标、事务与动态SQL全解析-代码聚汇网

MySQL存储过程实战指南：游标、事务与动态SQL全解析

我行我素12334·2026-08-29·阅读 23 GEO检测（免费）

MySQL存储过程游标动态SQL

|难度：普通|阅读约 17 分钟

1. 为什么说存储过程是"被低估的老手艺"

前阵子接手了一个跑了七八年的订单系统，业务代码里密密麻麻全是拼出来的SQL，一条统计语句能写上两百行，还动不动就超时。我把其中几段核心逻辑抽出来改成了MySQL存储过程，线上排查问题时不再需要翻半天日志去拼上下文，DBA做优化时也能直接对着过程体看执行计划。说实话，现在很多团队一提存储过程就皱眉，觉得这东西老、难维护、不如在应用层写逻辑，但真到了复杂报表、批量数据处理、事务边界控制这些场景，存储过程依然是数据库侧最稳的方案之一。

存储过程是什么？一句话：把一段或多段SQL逻辑预先编译并保存在数据库服务端，调用时通过过程名和参数直接执行。它和普通SQL最大的区别在于——普通SQL是"发一条、执行一条"，存储过程是"发一次调用、执行一整段逻辑"。这个差异在业务简单时看不出优势，但一旦逻辑里涉及循环、条件分支、多表联动、事务控制，收益会非常明显。

这篇文章的目标读者很明确：已经会写基础的增删改查，想在数据库侧做更复杂逻辑的新手；以及在系统性能优化过程中，想用存储过程替代部分业务代码的开发者。全文会从基本骨架讲到游标、异常处理、动态SQL，最后用一个完整的订单批量处理案例串一遍，并把我实际踩过的坑一并列出来。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. 存储过程的"骨架"：从最小可用版本说起

2.1 基本结构与创建语法

MySQL里创建存储过程的基础语法是CREATE PROCEDURE，我们先看一个最简单、能直接跑通的最小版本：

sql复制DELIMITER $$

CREATE PROCEDURE sp_hello()
BEGIN
    SELECT 'Hello, MySQL Procedure!';
END$$

DELIMITER ;

这里有两个新手最容易懵的点。第一个是DELIMITER $$，它的作用是把MySQL客户端的语句分隔符临时从分号改成$$。因为存储过程体内会包含多条以分号结尾的SQL，如果客户端仍然用分号作为分隔符，它会在第一个分号处就认为语句结束了，导致过程体被截断。执行完CREATE PROCEDURE后再用DELIMITER ;把分隔符改回来。

第二个点是BEGIN...END块，它代表了过程体的边界。无论过程体里是一条语句还是几十条语句，都必须放在这个块里。严格来说，如果过程体只有一条语句，BEGIN...END可以省略，但强烈建议永远写完整，因为后续任何一次逻辑增加，都要回来补这一层结构，何必呢？

调用方式就更简单了：

sql复制CALL sp_hello();

2.2 参数体系：IN、OUT、INOUT到底该怎么用

存储过程的参数有三种模式，这是面试高频点，也是实际开发里最容易用错的地方。

IN是默认模式，表示参数从外部传入，过程体内可以读取它，但不能把它作为输出返回。OUT方向正好相反，过程体内给它赋值，调用方在过程执行完后能拿到这个值。INOUT则是双向的：外部传入初始值，过程体内可以修改，结束时把最终值传回。

看一个能说明三者差别的例子：

sql复制DELIMITER $$

CREATE PROCEDURE sp_calc(
    IN  p_base   INT,
    OUT p_square INT,
    INOUT p_extra INT
)
BEGIN
    -- p_base 只能读
    SET p_square = p_base * p_base;
    -- p_extra 先读后写，传入的是原始值
    SET p_extra = p_extra + 100;
END$$

DELIMITER ;

-- 调用
SET @base = 6;
SET @extra = 50;
CALL sp_calc(@base, @square, @extra);
SELECT @square, @extra;

执行结果里，@square是36，@extra变成了150。注意OUT和INOUT参数在调用时必须传入变量（以@开头的用户变量），不能直接写常量，否则MySQL会报语法错误。这个细节我在早期开发时踩过，硬编码了一个数字传给OUT参数，结果数据库直接拒绝执行。

实际业务里，OUT参数最典型的应用是"返回操作影响的行数"或者"返回生成的流水号"，INOUT则常用于累加器或状态流转场景。

2.3 流程控制：IF、CASE与三种循环的正确姿势

流程控制决定了存储过程能不能承载"真正"的逻辑。先从分支开始：

sql复制IF p_score >= 90 THEN
    SET p_level = 'A';
ELSEIF p_score >= 60 THEN
    SET p_level = 'B';
ELSE
    SET p_level = 'C';
END IF;

注意MySQL里不存在ELSIF，它的写法是ELSEIF，少写一个E都不行。这个和Oracle的PL/SQL不太一样，Oracle用的是ELSIF，如果是从Oracle转过来的同学要特别小心。

分支还有一种CASE写法，适合多值匹配：

sql复制CASE p_status
    WHEN 1 THEN SET p_desc = '待支付';
    WHEN 2 THEN SET p_desc = '已支付';
    WHEN 3 THEN SET p_desc = '已发货';
    ELSE SET p_desc = '未知状态';
END CASE;

循环方面的选择就更多了。LOOP是一个无限循环，需要配合LEAVE跳出；WHILE是先判断后执行，条件不满足时一次都不执行；REPEAT是先执行后判断，至少执行一次。三者适用场景不同：

已知循环次数，且循环次数可能为0时，用WHILE。
至少需要执行一次的场景（比如先计算再判断结果），用REPEAT。
需要在循环体中间根据复杂条件跳出时，用LOOP + LEAVE。

举个实际例子，把1到100累加：

sql复制DELIMITER $$

CREATE PROCEDURE sp_sum()
BEGIN
    DECLARE v_i INT DEFAULT 1;
    DECLARE v_total INT DEFAULT 0;
    
    WHILE v_i <= 100 DO
        SET v_total = v_total + v_i;
        SET v_i = v_i + 1;
    END WHILE;
    
    SELECT v_total;
END$$

DELIMITER ;

这里有个非常容易踩的坑：MySQL不允许在DECLARE时给变量加@前缀。@开头的是用户变量，作用域是整个会话；而DECLARE声明的叫局部变量，只在过程体内有效。用户变量可以在存储过程里直接使用，但局部变量必须先声明。很多人混淆了两者，结果在DECLARE语句里写DECLARE @v_i INT，直接报语法错误。

关于变量还要注意一点：局部变量赋值有两种方式，SET和SELECT INTO。SET是标准赋值，SELECT INTO则能把查询结果直接写进变量：

sql复制SELECT COUNT(*) INTO v_count FROM orders WHERE status = 1;

前提是查询结果必须只有一行一列，否则MySQL会报错"Result consisted of more than one row"。如果查询可能返回多行，要么加LIMIT 1，要么改用聚合函数。

3. 游标、异常处理与动态SQL：真正拉开差距的地方

3.1 游标的正确遍历方式

游标的基本语义是"逐行处理查询结果集"。有时候我们需要把某张表的每一行取出来做计算，再决定是否插入另一张表，这种行级操作没法用普通SQL完成，这时候就得靠游标。

MySQL里游标的使用套路非常固定，就四步：声明、打开、取数、关闭。声明必须在变量声明之后：

sql复制DECLARE v_id INT;
DECLARE v_name VARCHAR(64);
DECLARE cur_user CURSOR FOR SELECT id, name FROM users WHERE status = 0;

打开和取数：

sql复制OPEN cur_user;
FETCH cur_user INTO v_id, v_name;

每次FETCH会把当前行的两个字段分别塞进v_id和v_name，然后游标自动向后移动一行。问题来了：如果结果集里已经没有下一行了，FETCH并不会自动停下来报错，而是触发"NOT FOUND"条件。所以循环遍历游标的标准姿势必须配合一个退出条件：

sql复制DECLARE CONTINUE HANDLER FOR NOT FOUND SET v_finished = 1;

然后在循环里判断v_finished。这个条件处理句柄必须声明在游标声明之后，否则MySQL会提示语法错误。

我见过很多初学者写的游标循环没有这个退出条件，结果进入无限循环，数据库CPU飙满，只能暴力kill掉连接。判断条件要放在FETCH之后，在循环体的开头先判断一次，否则最后一行处理完又FETCH一次触发NOT FOUND时会多执行一轮逻辑。

3.2 条件处理：DECLARE HANDLER的语义坑

DECLARE CONTINUE HANDLER是MySQL里处理异常的机制。它有两种行为模式：CONTINUE和EXIT。CONTINUE表示遇到条件后继续往下执行，EXIT表示遇到条件直接结束当前过程块。

最常见的用法是捕获"NOT FOUND"（用于游标判断）和捕获SQL异常：

sql复制DECLARE EXIT HANDLER FOR SQLEXCEPTION
BEGIN
    ROLLBACK;
    SELECT '发生异常，已回滚';
END;

在实际项目中，DECLARE EXIT HANDLER FOR SQLEXCEPTION经常和事务配合。如果过程体内有多个增删改操作，任何一个步骤失败，都应该回滚整个事务，避免出现"主表插入了但明细表没有"这种数据不一致。而CONTINUE则适用于"某一条数据有歧义不影响整体处理"的场景。

但这里有一个隐蔽的大坑：条件处理句柄的声明顺序会影响作用范围。MySQL要求HANDLER必须声明在游标和变量之后，并且同一类型的HANDLER如果声明了多个，只有第一个会生效。比如你既声明了CONTINUE HANDLER FOR NOT FOUND又声明了EXIT HANDLER FOR SQLEXCEPTION，这两者不冲突，可以并存。但如果你声明了两个CONTINUE HANDLER FOR NOT FOUND，只有第一个生效，而且MySQL不报错，只会在执行时静默忽略第二个。

另外，HANDLER的作用范围是它所在的BEGIN...END块。如果你在子块里声明了一个异常处理，它只会捕获子块内部发生的异常，外层块捕获不到。这个作用域特性在处理多段逻辑、每段需要不同异常策略时非常有用。

3.3 动态SQL：PREPARE + EXECUTE的安全用法

普通存储过程的过程体是固定的SQL，但有时我们需要根据参数拼出不同的表名、字段名或条件。比如一个分表场景：订单表按月拆分，输入月份参数后要查询对应的表。这时候必须用动态SQL。

MySQL里动态SQL的标准三件套是PREPARE、EXECUTE、DEALLOCATE PREPARE：

sql复制SET @sql = CONCAT('SELECT * FROM orders_', p_month, ' WHERE user_id = ?');
PREPARE stmt FROM @sql;
EXECUTE stmt USING @user_id;
DEALLOCATE PREPARE stmt;

注意几点：

拼接的动态SQL语句先放到用户变量@sql中，不能直接用局部变量。
可以通过?占位符传参数，USING子句传入具体值。用占位符而不是直接把值拼进SQL字符串，能有效防止SQL注入。
执行完必须DEALLOCATE PREPARE释放资源，否则会占用服务端预处理资源。

这里最容易被忽略的是：动态SQL里PREPARE不允许直接使用存储过程的局部变量。所以要把局部变量的值先赋给@用户变量，再拼接进SQL。另外，动态拼接的表名、字段名不能被参数绑定，只能拼进SQL字符串里，因此在传入外部输入时一定要校验白名单，比如检测表名是否匹配预期的正则或前缀。

动态SQL还有一个隐患是调试困难。SQL字符串是运行时生成的，EXPLAIN无法直接作用于动态语句。我的习惯是先写一个调试模式：把拼好的@sql通过SELECT @sql;输出到日志，确认无误后再关闭调试输出。这个习惯帮我省下了大量排查时间。

4. 一个完整案例：批量订单状态更新与对账标记

4.1 需求场景与表结构

光讲语法太散了，我拿一个实际需求来串一遍。假设我们有一个电商订单系统，每天需要把"已确认收货且超过7天无售后"的订单自动标记为"已完成"，并生成一条对账记录。这个任务如果用应用层代码做，需要先查一批订单号，逐条更新订单状态，再逐条插入对账表。整个过程分成三个步骤，很容易在中间步骤失败时产生数据不一致。

用存储过程实现的话，可以把三个步骤包在同一个事务里。先是表结构：

sql复制CREATE TABLE orders (
    id INT PRIMARY KEY AUTO_INCREMENT,
    order_no VARCHAR(32) NOT NULL,
    user_id INT NOT NULL,
    status TINYINT NOT NULL DEFAULT 0 COMMENT '0待支付 1已支付 2已发货 3已确认收货 4已完成',
    confirm_receipt_time DATETIME DEFAULT NULL,
    updated_at DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP
) ENGINE=InnoDB;

CREATE TABLE order_reconcile (
    id INT PRIMARY KEY AUTO_INCREMENT,
    order_id INT NOT NULL,
    order_no VARCHAR(32) NOT NULL,
    reconcile_time DATETIME DEFAULT CURRENT_TIMESTAMP,
    remark VARCHAR(255) DEFAULT ''
) ENGINE=InnoDB;

需求拆解下来有四个判断条件：

订单状态必须为3（已确认收货）。
confirm_receipt_time不能为空。
当前时间减去confirm_receipt_time要大于7天。
同一订单在order_reconcile表中不能已经有对账记录，避免重复处理。

4.2 存储过程的完整实现

创建这样一个批处理过程：

sql复制DELIMITER $$

CREATE PROCEDURE sp_auto_complete_orders()
BEGIN
    DECLARE v_done INT DEFAULT 0;
    DECLARE v_id INT;
    DECLARE v_order_no VARCHAR(32);
    DECLARE v_count INT DEFAULT 0;
    
    -- 游标：筛选出符合条件的订单
    DECLARE cur_orders CURSOR FOR 
        SELECT o.id, o.order_no
        FROM orders o
        LEFT JOIN order_reconcile r ON o.id = r.order_id
        WHERE o.status = 3
          AND o.confirm_receipt_time IS NOT NULL
          AND o.confirm_receipt_time < DATE_SUB(NOW(), INTERVAL 7 DAY)
          AND r.id IS NULL
        FOR UPDATE;
    
    DECLARE CONTINUE HANDLER FOR NOT FOUND SET v_done = 1;
    
    OPEN cur_orders;
    
    START TRANSACTION;
    
    REPEAT
        FETCH cur_orders INTO v_id, v_order_no;
        IF NOT v_done THEN
            -- 更新订单状态
            UPDATE orders SET status = 4 WHERE id = v_id AND status = 3;
            
            -- 插入对账记录
            INSERT INTO order_reconcile(order_id, order_no, remark)
            VALUES (v_id, v_order_no, '系统自动完成：确认收货超过7天');
            
            SET v_count = v_count + 1;
        END IF;
    UNTIL v_done END REPEAT;
    
    CLOSE cur_orders;
    
    COMMIT;
    
    SELECT v_count AS processed_count;
END$$

DELIMITER ;

这段代码的核心思路是：先用一条SQL把符合条件的订单查出来放进游标，然后逐行进行更新和插入。LEFT JOIN加上r.id IS NULL条件的写法，把"需要处理的订单"和"已经在对账表里的订单"在查询阶段就完成了过滤，游标取到的每一行都是必须处理的。

FOR UPDATE是关键一点。这个子句会在读取游标行时对相关记录加锁，防止另一个并发进程同时处理同一批订单。如果不加FOR UPDATE，两个定时任务同时执行时，极大概率出现重复插入对账记录的情况。加了之后，后启动的事务会阻塞，等前一个提交后再读取，这时候r.id IS NULL条件已经不满足了，自然就跳过。

4.3 验证脚本与边界测试

创建完成后，需要造几组测试数据来验证：

sql复制-- 正常应该被处理
INSERT INTO orders(order_no, user_id, status, confirm_receipt_time) 
VALUES ('NO20250101001', 1, 3, DATE_SUB(NOW(), INTERVAL 10 DAY));

-- 状态不符，不应被处理
INSERT INTO orders(order_no, user_id, status, confirm_receipt_time) 
VALUES ('NO20250101002', 2, 2, DATE_SUB(NOW(), INTERVAL 10 DAY));

-- 未到7天，不应被处理
INSERT INTO orders(order_no, user_id, status, confirm_receipt_time) 
VALUES ('NO20250101003', 3, 3, DATE_SUB(NOW(), INTERVAL 3 DAY));

-- 已有对账记录，不应被重复处理
INSERT INTO orders(order_no, user_id, status, confirm_receipt_time) 
VALUES ('NO20250101004', 4, 3, DATE_SUB(NOW(), INTERVAL 10 DAY));

INSERT INTO order_reconcile(order_id, order_no, remark) 
VALUES (4, 'NO20250101004', '手动对账');

跑完CALL sp_auto_complete_orders();后，检查订单表和对账表。预期结果是：NO20250101001被更新为4，并且对账表里多一条记录；其他三单状态不变。实测下来结果符合预期。

这个案例里藏着两个容易被忽略的经验。一是confirm_receipt_time < DATE_SUB(NOW(), INTERVAL 7 DAY)这个写法比TIMESTAMPDIFF(DAY, confirm_receipt_time, NOW()) > 7性能更好，因为前者能用上索引，后者对每一行都做函数计算，索引直接失效。二是游标循环里做了两件需要事务保护的事情，但START TRANSACTION必须放在OPEN cur_orders之后、FETCH之前，如果放在游标声明之前，MySQL会报错——因为游标声明不能出现在事务控制语句之后。

5. 生产环境里必须知道的坑与优化建议

5.1 调试方法论：没有调试器怎么排查问题

MySQL存储过程没有像IDE里那种断点调试，早期版本甚至只有简单的错误信息。这么多年实践下来，我常用的调试手段有三个。

第一个是"日志表法"。在过程体里往一张专门的调试日志表插入关键变量的值：

sql复制CREATE TABLE proc_debug_log (
    id INT AUTO_INCREMENT PRIMARY KEY,
    proc_name VARCHAR(64),
    log_info VARCHAR(255),
    log_time DATETIME DEFAULT CURRENT_TIMESTAMP
) ENGINE=InnoDB;

在关键步骤后插入：

sql复制INSERT INTO proc_debug_log(proc_name, log_info) 
VALUES ('sp_auto_complete_orders', CONCAT('当前处理订单: ', v_order_no, ', 新状态: ', v_new_status));

实测下来这是最接近断点调试的方案，可以在过程体里保留这些语句，上线时用条件变量控制是否写入。

第二个是SELECT输出法。在过程体里临时加SELECT语句把变量打出来，适合一次性排查，但注意生产环境不要留这种输出，否则调用方会收到非预期的结果集。

第三个是拆分法。把复杂过程体拆成多个小步骤，每段注释掉其他部分单独执行。比如先把游标查询单独拿出来看结果集是否正确，再用简单的UPDATE代替循环验证事务逻辑，最后拼装完整过程。这样可以缩小问题范围。

5.2 性能与锁的权衡

存储过程性能问题主要集中在三块：游标逐行处理、动态SQL无法预编译、锁冲突。

游标的本质是逐行处理，如果结果集有十万行，它就是十万次循环。很多场景其实可以用单条SQL代替。比如上面那个订单批量更新的案例，不用游标也可以做到，用一条多表UPDATE加一个INSERT SELECT合并操作会更高效：

sql复制UPDATE orders o
LEFT JOIN order_reconcile r ON o.id = r.order_id
SET o.status = 4
WHERE o.status = 3
  AND o.confirm_receipt_time IS NOT NULL
  AND o.confirm_receipt_time < DATE_SUB(NOW(), INTERVAL 7 DAY)
  AND r.id IS NULL;

两者对比的话，游标版的优势在于可以在循环里做更多个性化逻辑（比如每行处理前先查一下其他表），劣势是性能差。而集合SQL的优势是性能好，劣势是逻辑灵活性低。我的建议是：如果每行处理逻辑完全相同，优先用集合SQL；如果每行处理依赖前一行结果或需要查外部表，再考虑游标。

FOR UPDATE加锁会带来并发问题。如果处理的数据量大，事务打开时间就长，持锁时间也长，其他事务查询这些行都会被阻塞。处理大批量数据时，建议分批提交，比如每处理500行就COMMIT一次，避免长时间占用锁资源。

5.3 版本兼容与迁移注意事项

MySQL 5.7、8.0在存储过程语法上差异不大，主要的坑集中在默认字符集和SQL模式上。8.0默认是utf8mb4，如果建库时用了老旧的utf8，在过程体里做字符串拼接或比较时，遇到生僻字或多字节字符可能出现乱码。建议建库时统一用utf8mb4，并且在CREATE PROCEDURE时显式指定CHARACTER SET utf8mb4：

sql复制CREATE PROCEDURE sp_test()
    CHARACTER SET utf8mb4
BEGIN
    ...
END

还有一个高频坑：GROUP BY严格模式的差异。MySQL 5.7及以上默认开启ONLY_FULL_GROUP_BY，如果过程体里有SELECT非聚合字段且不在GROUP BY中，执行会直接报错。从老系统搬迁存储过程时，这类SQL报错最常见，应对方式是改写SQL，而不是关闭严格模式。

5.4 存储过程的权限管理与编码规范

存储过程创建时会以创建者的身份定义，但执行权限由DEFINER和SQL SECURITY控制。默认是SQL SECURITY DEFINER，意味着执行过程体时用的是创建者的权限。如果创建者权限很大，而调用者是普通用户，就可能出现越权风险。

建议明确指定安全模式并配合最小权限原则：

sql复制CREATE DEFINER='proc_user'@'localhost' PROCEDURE sp_test()
    SQL SECURITY DEFINER
BEGIN
    ...
END;

给proc_user只授予它需要操作的表权限，调用存储过程的业务账号则只给EXECUTE权限。这样即使过程体里有敏感的DELETE操作，普通用户也无法单独执行，只能通过过程体间接完成。

命名规范方面，我见过的团队各有一套。我个人的习惯是：

存储过程统一前缀sp_，触发器统一前缀trg_，函数统一前缀fn_。
名称用下划线分隔，动词开头，比如sp_get_user_orders、sp_update_order_status。
存储过程不过度复用，一个过程只做一件事。如果一个过程中的分支超过三层，要么拆成子过程，要么考虑用应用层代码替代。

我在实际项目里因为命名不规范吃亏过。早期过程名叫p1、p2，半年后连自己都想不起来p2是干什么的。后来强制推行这套命名规则，新接手的人看名字就知道作用，维护成本直线下降。存储过程本身是"最后一道防线"型的技术方案，一旦上线，修改成本比应用代码高得多，所以前期的命名、注释、权限规划一定要做到位，才能避免后续的麻烦。