靠谱，但仅适用于轻量、确定性高且无法前置到应用层的校验，如email格式、枚举值检查或空字符串拦截；跨表查询、外部调用或复杂计算应避免，否则易引发单点瓶颈、error 1442、隐式锁升级及死锁。
BEFORE INSERT 触发器里做业务校验，靠谱吗？
靠谱，但只适合轻量、确定性高、无法前置到应用层的校验。比如检查 email 格式是否合法、status 是否在预设枚举值内、或防止插入空字符串代替 NULL。一旦涉及跨表查（如“用户余额是否足够”）、调用外部服务、或复杂计算（如实时库存扣减），就该立刻放弃——触发器会变成单点瓶颈。
常见错误现象：ERROR 1442 (HY000): Can't update table 'xxx' in stored function/trigger because it is already used by statement which invoked this stored function/trigger，这是试图在 BEFORE INSERT 里更新同一张表导致的；还有隐式锁升级，让并发插入变慢甚至死锁。
- 校验逻辑必须是纯函数式：不读其他行、不写任何表、不依赖会话变量
- 避免调用
SELECT ... FROM same_table，哪怕只是COUNT(*) - 正则校验慎用：
REGEXP在 MySQL 8.0 前性能差，且无法走索引；优先用LIKE或应用层处理
MySQL 5.7 和 8.0 的 BEFORE INSERT 触发器行为差异
核心差异在事务可见性和执行时机。MySQL 5.7 中，BEFORE INSERT 触发器里的 SELECT 看不到当前事务中尚未提交的其他语句修改；而 MySQL 8.0 引入了原子 DDL，触发器内对同一事务中已修改数据的可见性更一致，但也更容易暴露竞态问题。
使用场景上，如果你依赖触发器做“插入前生成唯一编号”，5.7 可能因间隙锁表现不稳定；8.0 下推荐改用 UUID_TO_BIN(UUID(), 1) 或应用层分配 ID，避免触发器里查最大值加一（SELECT MAX(id)+1）这种反模式。
- 5.7 不支持在触发器中使用
GET_LOCK()，8.0 支持但极不推荐——会阻塞整个表插入 -
NEW.column在 5.7 和 8.0 都可赋值，但若列有默认值且你显式设为NULL，实际插入结果可能因 SQL mode（如STRICT_TRANS_TABLES）不同而报错 - 8.0 开启
binlog_format = ROW时，触发器修改NEW会影响 binlog 内容；5.7 下部分场景可能漏记录
性能开销到底有多大？怎么测才真实？
不是“加个触发器就慢 10%”，而是取决于触发器里干了什么。一个只做 IF NEW.price 的触发器，实测对批量插入吞吐影响几乎不可测（SELECT COUNT(*) FROM orders WHERE user_id = NEW.user_id，单条插入延迟可能从 0.2ms 涨到 15ms+，QPS 跌掉 70% 以上。
测试时别只压单条 INSERT，要模拟真实负载：用 LOAD DATA INFILE 或批量 INSERT ... VALUES (),(),()，并开启 performance_schema 查看 events_statements_history_long 中触发器相关事件耗时。
- 用
SHOW PROFILE FOR QUERY N看具体触发器执行占总时间比 - 监控
Handler_read_*状态变量，突增说明触发器引发额外扫描 - 注意 autocommit 关闭时，触发器执行时间会计入事务总耗时，容易误判为网络或应用层问题
替代方案比硬扛触发器更值得考虑
大多数所谓“必须数据库层校验”的需求，其实只是没把边界控制好。比如防重复下单，与其在 BEFORE INSERT 查订单表，不如建唯一索引 UNIQUE KEY (user_id, order_no)；比如状态流转校验，更适合用带条件的 UPDATE ... WHERE status = 'draft'，失败即说明状态非法。
真正绕不开触发器的场景极少：审计字段自动填充（created_at, created_by）、分库分表中间件缺失时的 ID 生成、遗留系统无法改应用代码。即便如此，也建议把复杂逻辑拆到存储过程里，触发器只做简单调用，方便单独压测和替换。
- 应用层校验 + 唯一约束 + 条件更新，覆盖 90% 以上业务校验需求
- 如果用了 ORM，多数支持 pre-save hook（如 Django 的
save()重载、TypeORM 的@BeforeInsert），比触发器更可控 - 触发器调试困难、版本难管理、上线易遗漏，这些隐性成本远高于写几行应用代码
触发器不是不能用，是它太容易被当成“兜底方案”来掩盖设计缺陷。一旦发现需要在触发器里写循环、临时表或异常捕获，基本可以判定：这里该重构了。
