能，但需用 SIGNAL 主动报错终止；BEFORE INSERT 触发器可校验并拒绝非法数据，但不能跳过或改写插入，必须通过 SIGNAL SQLSTATE 报错，且仅支持 MySQL 5.5+。
触发器能做 insert 前校验吗？能，但有硬限制
MySQL 的 BEFORE INSERT 触发器确实可以拦截并拒绝非法数据，但它不能“跳过插入”或“改写 SQL”，只能通过抛出错误来中止操作。这意味着：校验失败时必须用 SIGNAL 主动报错，而不是靠 return 或 silent ignore —— 后者在 MySQL 触发器里根本不存在。
常见错误现象：Truncated incorrect DOUBLE value 或静默插入成功，往往是因为写了 IF ... THEN SET @x = 1; 却没跟 SIGNAL，误以为逻辑已生效。
- 必须使用
SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'xxx';终止流程 - MySQL 5.5+ 才支持
SIGNAL；低版本只能靠构造非法赋值（如SET @x = 'abc' / 0;）间接报错，不推荐 - 触发器里不能调用存储函数以外的外部逻辑（比如 HTTP 请求、文件读写）
BEFORE INSERT 触发器里怎么写校验逻辑？
核心是把校验条件转成 IF 判断 + SIGNAL 报错。注意字段引用用 NEW.column_name，且只能读不能写（除非你真想改数据）。
使用场景：比如要求 email 字段必须含 @，且长度不超过 254 字符；status 只能是 'active'、'inactive' 之一。
DELIMITER $$
CREATE TRIGGER check_user_insert
BEFORE INSERT ON users
FOR EACH ROW
BEGIN
IF NEW.email NOT LIKE '%_@__%.__%' OR CHAR_LENGTH(NEW.email) > 254 THEN
SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'Invalid email format or length';
END IF;
IF NEW.status NOT IN ('active', 'inactive') THEN
SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'status must be active or inactive';
END IF;
END$$
DELIMITER ;
-
NEW是唯一可用的行上下文，OLD在 INSERT 中不可用 - 正则匹配要用
REGEXP（MySQL 8.0+ 支持更全），但简单模式用LIKE性能更好 - 避免在触发器里查其他表（如
SELECT ... FROM another_table），会显著拖慢批量插入
为什么有时候触发器没生效？几个典型坑
不是语法错，而是环境或权限导致“看起来没运行”。最常被忽略的是：触发器只对直接 INSERT 生效，对 LOAD DATA INFILE、INSERT ... SELECT（某些版本）、或 ORM 自动生成的批量语句可能被绕过。
- 用户账号必须有
TRIGGER权限，否则创建成功但执行时报ERROR 1227 (42501) - 从库默认禁用触发器（
replicate_do_trigger相关参数需配），主从一致性校验时容易漏掉 - 触发器里的错误不会写入 general log，只出现在客户端报错和 error log（需开
log_error_verbosity=3） - 如果表用了
ROW_FORMAT=COMPRESSED或加密表空间，部分旧版 MySQL 会跳过触发器执行
比触发器更稳的数据校验方案有哪些？
触发器是最后防线，不是首选。它难测试、难调试、无法复用、还可能被 INSERT IGNORE 或 ON DUPLICATE KEY UPDATE 绕过。
真正可靠的顺序是：应用层校验 → 数据库约束（CHECK、NOT NULL、ENUM）→ 触发器兜底。MySQL 8.0.16+ 支持原生 CHECK 约束，应优先用它代替简单逻辑：
ALTER TABLE users ADD CONSTRAINT chk_email_format
CHECK (email REGEXP '^[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Za-z]{2,}$');
-
CHECK约束自动生效、可被EXPLAIN识别、支持索引优化，且报错信息更标准 - 触发器适合跨字段逻辑（如 “discount > 0 仅当 is_promo = 1”），而单字段格式校验交给
CHECK更干净 - ORM 框架（如 Django、Laravel）的模型验证层，比数据库层更容易做用户友好的提示
复杂业务规则耦合在触发器里，时间一长连自己都看不懂 —— 尤其是带子查询或临时变量的那段逻辑，下次修 bug 时你会回来翻这篇。
