MySQL 存储过程怎么把错误传给调用方：SIGNAL、RESIGNAL 与事务回滚边界

订单写入存储过程时，库存、金额或状态校验失败，最怕调用方只收到一条模糊的“数据库错误”。MySQL 可以用 SIGNAL 主动构造可识别的异常，再用 RESIGNAL 在处理器里保留原始诊断信息；但异常本身不会替你完成事务回滚，回滚动作必须在过程逻辑里明确写出。

SIGNAL 负责把业务失败变成可传递的 SQL 异常，RESIGNAL 负责重抛或补充诊断信息；是否回滚，要看显式事务处理和存储引擎状态。

先用一条 SIGNAL 把业务校验失败说清楚

假设下单流程在扣减库存前先校验购买数量。数量小于 1 时，不用等到触发约束错误再让调用方自行排查原因，可以直接返回自定义 SQLSTATE 和错误号：

IF p_quantity 

45000 表示未进一步细分的用户定义异常。真正给应用做分支判断时，建议约定自己的错误号范围，并把可读消息用于日志和排查，不要让前端依赖易变的整句文本。

把异常字段变成调用方能验收的契约

应用侧不能只做“调用失败”的笼统判断。测试过程中，可以故意传入0值这类非法数量，观察客户端捕获到的 SQLSTATE、错误号和消息是否和存储过程的约定完全一致。数据库工具展示的错误文本可能附带驱动自身的前缀，所以验收优先级优先看结构化的错误字段，不要只比对字符串内容。

CALL create_order(101, 0, 2);

-- 预期：SQLSTATE 45000
-- MYSQL_ERRNO 30001
-- 消息包含 quantity

刚开始实现的时候不需要急着加大量自定义错误号。一套统一维护的业务错误映射表，比散落在十几个存储过程里的临时错误编号更容易管理；后续需要兼容旧客户端的场景下，哪怕调整错误提示文案，也不要随便更换已对外发布的错误编号。

RESIGNAL 适合保留底层原因再补一层上下文

过程调用了另一个子过程，底层可能抛出死锁、约束或库存异常。外层处理器可以先记录必要信息，再用 RESIGNAL 原样重抛：

DECLARE EXIT HANDLER FOR SQLEXCEPTION
BEGIN
  -- 这里可写审计记录，但不要吞掉异常
  RESIGNAL;
END;

如果确实要把消息补成更接近业务的描述，可以在 RESIGNAL 中改写部分诊断项，同时保留原来的 SQLSTATE：

DECLARE EXIT HANDLER FOR SQLEXCEPTION
BEGIN
  ROLLBACK;
  RESIGNAL SET MESSAGE_TEXT = 'create order failed';
END;

两种写法的选择逻辑很清晰：底层原始错误信息对排障帮助更大的时候直接原样重抛；调用方只需要明确的业务语义时，可以改写提示文案但保留可追踪的核心错误编号。不要在异常处理器里静默吞掉错误直接结束流程，否则上层调用方会误以为存储过程执行成功，后续数据逻辑会完全乱掉。

SIGNAL 不会自动替你回滚已经写入的行

这是很多人最容易误解的细节。异常会改变代码控制流，但事务边界仍然由事务语句和存储引擎的规则决定。如果存储过程先写入订单数据，再写入库存数据，最后才执行 SIGNAL 抛出异常，而异常处理器里没有写显式回滚逻辑，绝对不能默认“过程抛出报错，前面的写入操作一定会自动撤销”。

START TRANSACTION;
CALL create_order(101, 2, 1);

-- 过程内部异常处理器：
-- ROLLBACK;
-- RESIGNAL;

COMMIT;

更稳妥的过程边界是：由过程统一负责失败时的 ROLLBACK，成功路径才返回给调用方提交；或者明确规定事务由外层服务管理，并在接口文档中写出失败后的状态检查方式。两种模型都能用，混用才危险。

用四个结果核对一次完整的错误路径

不能只在客户端看到异常就直接确认流程没问题。针对同一个测试订单号，至少要记录调用前后的订单状态、库存数量、错误三字段和事务连接状态：

1. 传入非法数量，确认收到 45000 / 30001，订单表没有新增行。
2. 模拟子过程异常，确认外层 handler 没有吞错，RESIGNAL 仍能到达调用方。
3. 让写入发生后再失败，确认显式 ROLLBACK 后订单和库存回到调用前状态。
4. 跑一遍全量成功路径，确认所有校验通过后才正式提交，提交完成后再次查询库存差额确认扣减正确。

常见问题：错误传递和事务边界怎么判断

只写 SIGNAL，不声明 handler，可以吗？

不需要额外定义异常处理器。存储过程会在当前位置直接抛出异常并终止后续逻辑，只有需要统一做错误日志记录、资源清理或者改写自定义错误信息的场景，才需要专门声明 handler。

RESIGNAL 会不会自动撤销 INSERT？

不会自动回滚写入操作。RESIGNAL 只负责修改诊断信息和调整控制流，是否撤销之前的写入操作完全由显式回滚语句和正确的事务边界控制，和 RESIGNAL 本身没有直接关联。

错误号应该让前端直接展示吗？

错误号适合应用侧做稳定的分支判断和监控聚合，面向普通用户的提示文案应该由业务层根据错误号统一映射生成，不要把数据库内部的原始错误消息直接暴露给前端用户。

最后把过程契约写进回归用例

一套可长期维护的 MySQL 存储过程错误处理逻辑，不是把异常提示消息写得越长越好，而是要保证失败场景能快速定位、事务状态能可复现可证明。把约定的 SQLSTATE、业务错误号、是否自动回滚、订单和库存的验收结果都写入回归用例，后续修改存储过程逻辑或者替换客户端驱动的时候，才能第一时间发现错误被静默吞掉或者出现数据残留的问题。