MySQL SIGNAL 怎样把存储过程错误信息返回给调用方

我在把业务校验下沉到 MySQL 存储过程时，最先遇到的不是语法问题，而是调用方只能看到“执行失败”，却不知道是参数不合法、状态不允许，还是底层语句出了错。解决这类问题的关键是把数据库错误做成一份稳定契约：用 SIGNAL 抛出明确的 SQLSTATE，再按需要设置 MESSAGE_TEXT 和 MYSQL_ERRNO。

这篇只围绕 MySQL 存储过程中的 SIGNAL 展开。官方文档说明，它可以把错误信息交给 handler、外层程序或客户端；错误信息并不等于返回一个普通的结果集，所以应用层应当从异常对象或驱动提供的错误字段中读取它。

先把 SIGNAL 当成错误契约，而不是打印语句

SIGNAL 至少要有一个条件值，可以直接写 SQLSTATE，也可以引用一个用 SQLSTATE 声明的命名条件。业务校验失败时通常使用 45000，它代表未处理的用户定义异常。不要使用以 00 开头的值，那一类表示成功，不是合法的 SIGNAL 错误状态。

我觉得这里最容易踩的坑，是把“提示一下”写成警告。以 01 开头的 SQLSTATE 属于 warning，存储过程通常会继续执行；以 02 表示 not found；大于 02 的类别会按 exception 处理。需要阻止后续写入时，应选择异常级别，而不是只设置一条可忽略的 warning。

最小写法：在入口处返回 SQLSTATE、错误号和提示

下面的存储过程把订单数量校验放在写入前。代码里的三个字段分别承担不同职责：SQLSTATE 是较稳定的状态分类，MYSQL_ERRNO 方便日志或监控聚合，MESSAGE_TEXT 给开发者和调用方一个可读说明。

DELIMITER //

CREATE PROCEDURE create_order(IN p_quantity INT)
BEGIN
  -- 先在写表之前阻止无效数量，避免半完成的数据变更。
  IF p_quantity 

调用方收到的是异常，而不是一个代表失败的普通 SELECT 结果。应用层应当把状态、错误号和消息分别记录，避免只把中文消息当作机器判断条件。错误号属于本项目的约定，最好在团队内维护一张不重复的错误码表。

MESSAGE_TEXT 和 MYSQL_ERRNO 怎样避免写成不稳定接口

MESSAGE_TEXT 适合给人看，MYSQL_ERRNO 适合程序或日志系统做分类。MySQL 文档列出了可设置的 condition information item，消息文本最大长度和错误号类型都有边界；不要把一整段堆栈或敏感参数直接塞进消息里。

CREATE PROCEDURE check_balance(IN p_balance DECIMAL(12, 2))
BEGIN
  -- 机器判断依赖稳定错误号，文本只补充排查上下文。
  IF p_balance 

这里不要把用户输入原样拼进错误文本。对于可能包含身份证号、令牌、内部路径或 SQL 片段的值，应该只返回脱敏后的业务字段。数据库错误会进入应用日志，错误消息的设计也属于日志安全的一部分。

handler 中怎样读取并重新抛出错误

如果存储过程需要记录一条审计信息，或者把底层错误映射成团队统一的错误码，可以声明 EXIT 或 CONTINUE handler。handler 的声明必须放在变量和条件声明之后；真正要保留触发 handler 的原始错误时，我会优先读取 stacked diagnostics，再决定是否 RESIGNAL。

DELIMITER //

CREATE PROCEDURE save_profile(IN p_name VARCHAR(80))
BEGIN
  DECLARE v_errno INT;
  DECLARE v_state CHAR(5);
  DECLARE v_message TEXT;

  -- EXIT handler 负责采集原始错误，避免异常后继续执行写入流程。
  DECLARE EXIT HANDLER FOR SQLEXCEPTION
  BEGIN
    -- STACKED 诊断区保存触发 handler 的那一个条件。
    GET STACKED DIAGNOSTICS CONDITION 1
      v_errno = MYSQL_ERRNO,
      v_state = RETURNED_SQLSTATE,
      v_message = MESSAGE_TEXT;

    -- 实际项目可在此写审计表，但不要泄露敏感输入。
    INSERT INTO db_error_log(error_no, sql_state, error_message)
    VALUES (v_errno, v_state, LEFT(v_message, 128));

    -- 让调用方仍然收到可识别的异常，而不是静默成功。
    RESIGNAL;
  END;

  -- 具体写入语句失败时，控制权会转给上面的 handler。
  INSERT INTO user_profile(display_name)
  VALUES (p_name);
END//

DELIMITER ;

当前诊断区可能被 handler 内后续语句清空或改写，而 stacked diagnostics 用来保留触发 handler 的条件。若只是想把错误继续传给调用方，RESIGNAL 比重新拼一个模糊消息更可靠；只有在确实需要统一错误契约时，才用新的 SIGNAL 映射。

GET DIAGNOSTICS 与 SHOW ERRORS 应该怎么选

排查时可以先记住三个层次：

MySQL 官方文档还提醒，多条件场景下不能想当然地固定读取 condition 1 来代表主错误；需要先取 NUMBER，再决定读取哪个 condition。这个细节在一个语句同时产生多个 warning 或 error 时尤其重要。

BEGIN
  DECLARE v_count INT DEFAULT 0;
  DECLARE v_errno INT;

  -- 先获得诊断区中的条件数量，再读取最后一个条件。
  GET DIAGNOSTICS v_count = NUMBER;
  IF v_count > 0 THEN
    GET DIAGNOSTICS CONDITION v_count
      v_errno = MYSQL_ERRNO;
  END IF;
END

我会怎样给这类错误定规则

实际落地时，我会把规则压缩成四条：入口校验失败使用统一的 45000 与项目错误号；可继续执行的提示才使用 warning 类 SQLSTATE；handler 需要保留原始原因时先读 stacked diagnostics；调用方只依赖错误号和状态，不依赖容易变化的中文句子。

还有一个容易被忽略的边界：SIGNAL 是显式抛出用户定义条件，严格模式和 IGNORE 都不会把它变成“悄悄跳过”。所以它适合做明确失败，但不适合替代所有业务返回值。对于允许部分成功、需要返回多条校验结果的接口，应该设计结果集或批量错误结构，而不是连续 SIGNAL。

相关问题

SQLSTATE 45000 是 MySQL 专用错误码吗？

它是通用的用户定义异常状态值，MySQL 文档把它作为 generic SQLSTATE 示例。项目仍应自行约定错误号和消息，不要把 45000 当作能表达所有业务原因的唯一字段。

SIGNAL 后还能继续执行同一个存储过程吗？

如果发出的是异常类 SIGNAL，且没有 handler 接住，当前过程会终止；warning 类 SIGNAL 通常不会终止。需要阻止写入时，应把校验放在写入之前并使用异常类状态。

为什么 handler 里读不到原来的错误？

handler 内的语句可能改变当前诊断区。要读取触发 handler 的原始条件，优先使用 GET STACKED DIAGNOSTICS，并把读取动作放在会执行 INSERT、SELECT 或其它 SQL 之前。

把 SIGNAL 用成清晰的错误契约后，数据库侧的失败就不再是一句模糊的“调用失败”：状态负责分类，错误号负责稳定映射，消息负责解释，诊断区负责在 handler 内保留上下文。对我来说，这比在每个调用方里猜测 MySQL 原始错误更容易维护。