MySQL 存储过程怎样用 SIGNAL 返回可读的业务错误

存储过程里遇到库存不足、状态不允许或参数不符合业务规则时，直接让调用方看到一串难以区分的数据库错误，后续处理会很被动。MySQL 的 SIGNAL 可以主动抛出一个条件，并同时携带 SQLSTATE、MySQL 错误码和可读消息。

最小可用做法是：在业务条件成立时使用 SIGNAL SQLSTATE '45000'，再用 SET MYSQL_ERRNO=... 和 MESSAGE_TEXT='...' 补齐错误载荷；调用方根据 SQLSTATE 和错误码做分类，根据消息做展示或日志记录。

官方地址：https://dev.mysql.com/doc/refman/8.4/en/signal.html

本文只讨论存储过程中的业务错误表达和调用方读取，不把 SIGNAL 当成连接重试机制，也不延伸到客户端框架的具体异常类。

SIGNAL 返回的不是一段普通字符串

先把错误拆成三个层次，会比只关注 MESSAGE_TEXT 更容易维护。SQLSTATE 用来表示条件类别，MYSQL_ERRNO 适合在同一类业务错误中继续细分，MESSAGE_TEXT 则是给日志和人阅读的解释。

这样设计后，调用方不必通过匹配中文句子猜测原因。分类看 SQLSTATE，精确分支看错误码，日志或界面文案再使用消息文本。

在业务条件中用 SIGNAL 抛出错误

下面用一个扣减库存的例子说明位置。过程先判断数量是否足够，条件成立时立即发出业务错误；正常路径则继续更新数据。示例中的注释只解释关键参数，实际项目应把库存更新和判断放在同一事务边界里。

DELIMITER //

CREATE PROCEDURE deduct_stock(IN p_product_id BIGINT, IN p_quantity INT)
BEGIN
    DECLARE v_stock INT;

    -- 先读取当前库存，业务代码中应结合事务隔离策略保护这次判断。
    SELECT stock INTO v_stock
      FROM product_stock
     WHERE product_id = p_product_id;

    -- 数量不合法或库存不足时，返回稳定的业务错误载荷。
    IF p_quantity 

这里的 45000 是通用的用户定义异常类，重点是它不属于成功类 SQLSTATE。30001 是应用团队自定义的细分码，应该在接口文档或错误码表中固定下来。消息只描述业务结果，避免直接暴露表结构、内部路径或用户隐私。

调用方怎样读取三类错误字段

调用方收到过程调用失败时，应先判断这是业务拒绝还是数据库、网络等基础故障。业务拒绝通常可以直接提示用户修正输入或刷新状态；基础故障则要按连接池、事务和重试策略处理。两者不要只靠消息文本区分。

不同驱动的异常对象命名不同，但通常都能取得 SQLSTATE、MySQL 错误码和消息。建议在数据访问层先转换成项目自己的错误结构，再让上层决定展示、埋点或重试。

-- 这个调用示例用于说明失败分支由调用方接收，不代表要在过程内吞掉错误。
CALL deduct_stock(101, 8);

ERROR 30001 (45000): 库存不足，无法完成扣减

输出里可以把 30001 交给程序分支，把 45000 作为异常类别，把后面的中文消息写入日志或展示层。不要把输出中的文字顺序当成跨驱动的接口契约，真正稳定的契约应是字段和值。

四个容易踩到的边界

不要使用成功类 SQLSTATE

SQLSTATE 前两位为 00 的值表示成功类条件，不适合拿来表示业务拒绝。给自定义业务错误选择非成功类值，并在团队内统一约定，比让不同过程各自发明一套值更清楚。

不要把 SIGNAL 当成重试指令

SIGNAL 负责把条件传给调用方，不负责修复锁等待、网络中断或服务不可用。调用方是否重试要依据错误类别和幂等设计决定，库存不足这类业务拒绝通常不应盲目重试。

注意存储程序中的声明和作用域

如果使用命名条件，先在适用作用域内声明，并让名称与 SQLSTATE 建立清楚的对应关系。否则阅读过程代码时，很难判断一个条件究竟代表哪类业务失败。

不要把动态 SQL 当成 SIGNAL 的替代写法

MySQL 文档明确列出了条件处理语句的限制，SIGNAL、RESIGNAL 和 GET DIAGNOSTICS 不能作为预处理语句执行。需要动态参数时，应把动态部分限制在真正需要的查询语句，错误表达仍保持静态、可读。

总结

MySQL 存储过程使用 SIGNAL 时，关键不是拼一段更长的错误消息，而是同时设计错误类别、稳定编号和可读说明。用 SQLSTATE 做大类，用 MYSQL_ERRNO 做细分，用 MESSAGE_TEXT 做解释，调用方再转换成自己的错误结构，就能让业务拒绝与基础故障各走各的处理路径。

常见问题

SQLSTATE 一定要使用 45000 吗？ 不一定，但自定义业务异常应选择非成功类值，并保持团队约定一致。

MYSQL_ERRNO 可以省略吗？ 可以，但省略后调用方少一个稳定的细分依据；对需要多种业务分支的过程，建议显式设置。

MESSAGE_TEXT 适合直接给用户看吗？ 简单场景可以，复杂系统更适合先转成错误码，再由应用层选择本地化或更合适的提示。