应用层的业务校验很容易因为多个写入入口而失效，比如手工导数据、定时任务、其他服务直接调用数据库等。MySQL 触发器可以在数据真正写入表之前运行检查逻辑，如果发现数据不满足规则，就通过 SIGNAL 语句主动抛出一个错误，让本次 INSERT 或 UPDATE 直接失败。这样一来，业务约束就不再只是程序代码里的口头约定，而成为数据库层面的强制规则。触发器中的抛错并不是简单地返回提示，它会中断当前 SQL 语句并触发事务回滚行为，对保护数据一致性非常有价值。
一、为什么需要把业务约束下沉到触发器
在多数项目中，金额必须大于零、库存不能为负、状态不能逆向流转等规则通常写在服务层。服务层校验的优势是灵活，可以给用户返回友好的提示，也便于做国际化。但服务层校验有一个明显短板：它只能约束通过该服务入口写入的数据。一旦有其他程序、脚本或者数据库客户端直接操作表，这些规则就可能被绕过，最终产生脏数据。
数据库层本身有一些约束手段，例如 NOT NULL、UNIQUE、CHECK、外键等，但 MySQL 的 CHECK 约束在较旧的版本中长期不生效，而且一些复杂业务规则很难用列级约束表达。比如订单从已取消状态不能改为已支付，或者库存扣减后不能为负数，这类跨列、跨状态、依赖旧值的规则，更适合用触发器实现。触发器挂载在表上，对所有写入路径生效，无论数据来自哪个应用、哪个工具，只要执行 INSERT、UPDATE 或 DELETE，触发器都会执行。
把规则下沉到触发器还能减少应用代码的重复校验。多个服务模块可能都要写同一张表，如果每个模块都自己实现一遍校验，逻辑很容易不一致。触发器集中维护这些规则后，应用层可以继续保留校验以提高交互体验，但数据库层会提供最后一道防线。即使某个新模块忘记校验，也不会破坏核心数据。
二、SIGNAL 语句与触发器抛错语法
MySQL 从 5.5 版本开始支持 SIGNAL 语句，它可以在存储过程和触发器中使用，用来主动抛出错误。SIGNAL 的核心作用不是返回普通结果，而是中断当前语句执行，并向客户端返回一个错误码和错误消息。对于触发器来说，抛错意味着当前正在执行的 INSERT、UPDATE 或 DELETE 会失败，已经产生的行级变更将被回滚。
SIGNAL 的基本语法如下：
SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = '自定义错误信息';
其中 SQLSTATE '45000' 是常见用法，45000 属于用户自定义异常范围，表示由应用程序或触发器主动抛出的业务错误。使用 45000 可以避免和系统内置错误码冲突，客户端也能通过 SQLSTATE 识别这是一条业务规则错误，而不是数据库本身的故障。此外还可以通过 MESSAGE_TEXT 设置错误详情，通过 MYSQL_ERRNO 补充错误号，不过错误号不是必填项。
在触发器中抛错时，通常选择 BEFORE 触发器而不是 AFTER 触发器。BEFORE 触发器在数据写入前执行，一旦发现不合规就可以立即阻止写入，避免数据库先做无效的变更再回滚。AFTER 触发器虽然也能抛错并回滚，但已经过了实际写入阶段，开销更大，语义也不如 BEFORE 清晰。因此在强制业务约束的场景中，优先使用 BEFORE INSERT 和 BEFORE UPDATE。
三、实战案例：用 BEFORE 触发器拦截非法数据
先看一个库存约束的例子。假设有一张库存表，要求库存数量不能为负数。可以先创建表结构，再创建触发器：
CREATE TABLE inventory (
id INT PRIMARY KEY AUTO_INCREMENT,
product_id INT NOT NULL,
stock INT NOT NULL
);
DELIMITER $$
CREATE TRIGGER trg_inventory_stock_check
BEFORE INSERT ON inventory
FOR EACH ROW
BEGIN
IF NEW.stock < 0 THEN
SIGNAL SQLSTATE '45000'
SET MESSAGE_TEXT = '库存数量不能为负数';
END IF;
END$$
DELIMITER ;
这个触发器在每次 INSERT 前检查 NEW.stock，如果小于 0 就抛出错误。执行下面这条插入语句时，会得到类似 ERROR 1644 (45000): 库存数量不能为负数 的提示，插入操作不会成功。对于 UPDATE 也可以创建类似触发器，在更新前检查更新后的值。
第二个案例涉及订单金额和状态流转。订单金额必须大于零，已经取消的订单不能再次变更状态，已支付的订单也不能回退为待支付。先创建订单表：
CREATE TABLE orders (
id INT PRIMARY KEY AUTO_INCREMENT,
order_no VARCHAR(32) NOT NULL,
amount DECIMAL(10,2) NOT NULL,
status ENUM('PENDING','PAID','CANCELLED') NOT NULL DEFAULT 'PENDING'
);
DELIMITER $$
CREATE TRIGGER trg_orders_amount_check
BEFORE INSERT ON orders
FOR EACH ROW
BEGIN
IF NEW.amount <= 0 THEN
SIGNAL SQLSTATE '45000'
SET MESSAGE_TEXT = '订单金额必须大于0';
END IF;
END$$
DELIMITER ;
金额检查触发器能阻挡金额为零或负数的插入。状态流转检查则需要结合 OLD 和 NEW 两个值，因为只有 UPDATE 场景下才存在修改前和修改后的记录。触发器可以这样写：
DELIMITER $$
CREATE TRIGGER trg_orders_status_check
BEFORE UPDATE ON orders
FOR EACH ROW
BEGIN
IF OLD.status = 'CANCELLED' AND NEW.status != 'CANCELLED' THEN
SIGNAL SQLSTATE '45000'
SET MESSAGE_TEXT = '已取消订单不能变更状态';
END IF;
IF OLD.status = 'PAID' AND NEW.status = 'PENDING' THEN
SIGNAL SQLSTATE '45000'
SET MESSAGE_TEXT = '已支付订单不能回退为待支付';
END IF;
END$$
DELIMITER ;
这些规则写在触发器里后，任何试图把已取消订单重新激活，或者把已支付订单改回待支付的操作都会直接失败。即使有多个应用同时操作订单表，业务状态也不会被错误地改写。需要注意的是，触发器内可以写多个 IF 分支，每条分支都可以使用不同的错误消息，便于客户端根据消息定位问题来源。
四、触发器约束的边界、事务与调试建议
触发器抛错会中断当前 SQL 语句，但它对事务的影响取决于事务的调用方式。如果单条 INSERT 或 UPDATE 没有显式开启事务，MySQL 会自动提交并回滚该语句的变更。如果客户端已经使用 START TRANSACTION 开启事务，触发器中抛错只会让当前语句失败，不会自动回滚整个事务。此时客户端可以选择 ROLLBACK 回滚之前所有语句，也可以在存储过程或程序中通过 DECLARE HANDLER 捕获错误后继续执行其他逻辑。
性能方面，触发器在每行数据写入前都会执行一次，因此适合放置轻量级判断逻辑。避免在触发器中执行复杂查询、远程调用或大批量子查询，否则批量导入数据时会明显变慢。对于大量写入的场景，建议只把最核心、最容易破坏数据一致性的规则放到触发器中，更多展示性、交互性校验仍然可以保留在应用层。
调试触发器时，最容易遇到的问题有两个：一是错误消息没有按预期显示，二是触发器创建成功但没有生效。前者需要检查 SIGNAL 语句中的 MESSAGE_TEXT 是否正确设置，后者则要确认触发器的触发时机是否为 BEFORE 或 AFTER，以及监听的事件是否匹配。执行 SHOW TRIGGERS 可以查看触发器定义，使用 DROP TRIGGER 可以删除后重建。为了便于维护，触发器名称最好带上表名和业务含义，例如 trg_orders_amount_check 一眼就能看出它是订单金额检查触发器。
最后要明确，触发器不是银弹。它适合强制关键业务约束，但不应把大量业务逻辑都塞进数据库，否则会削弱可维护性。合理的做法是：应用层负责友好提示和复杂业务编排，数据库层用触发器、约束和外键守住数据底线。两者配合，才能在多入口写入环境中保证数据质量。
MySQL触发器SIGNAL SQLSTATE业务约束修改时间：2026-08-21 16:20:06