应同时创建 BEFORE INSERT 和 BEFORE UPDATE 触发器，用 SIGNAL 抛出异常校验 age 范围，避免静默赋值或跨表写操作，8.0+ 优先使用 CHECK 约束。
MySQL 触发器里怎么实现类似 CHECK 的字段范围校验
MySQL 5.7 及更早版本不支持 CHECK 约束（即使写了也不生效），8.0.16+ 虽然支持，但部分旧项目仍用触发器兜底。想限制插入值在某个范围内（比如 age 必须是 0–150），不能只靠应用层，得在数据库侧拦截——触发器是最直接的手段。
关键不是“能不能写”，而是“写在哪、怎么写才不漏掉、不报错”。常见错误是只在 BEFORE INSERT 里校验，却忘了 BEFORE UPDATE 同样可能破坏数据一致性。
- 必须同时定义
BEFORE INSERT和BEFORE UPDATE两个触发器，或合并为一个（MySQL 8.0.19+ 支持多事件触发器，但兼容性差，建议分开） - 校验失败时用
SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'age must be between 0 and 150'主动抛异常，不能只写SET NEW.age = NULL——后者会静默截断，违反业务意图 - 注意
NEW别名只在行级触发器中可用，且仅对当前操作行有效；若表有自增主键或默认值，NEW已含默认填充结果，校验逻辑要基于它，而非原始语句值
为什么不用存储过程替代触发器做插入前校验
能用，但不推荐。存储过程需要显式调用，而业务代码可能绕过它直连 INSERT，导致校验失效。触发器是强制钩子，只要走 DML 就触发。
更大的问题是性能和可维护性：
- 每个插入都要进一次存储过程调用栈，比原生触发器多一层解析开销
- 触发器逻辑绑定在表上，
SHOW CREATE TRIGGER一眼可见；存储过程分散在 schema 中，查起来费劲 - ORM（如 Django ORM、MyBatis）通常不感知存储过程，容易漏掉适配
触发器中访问其他表做关联校验会不会锁表
会，而且风险不小。比如在 BEFORE INSERT 触发器里查 SELECT COUNT(*) FROM limits WHERE category = NEW.category，这个 SELECT 默认加的是共享锁（S 锁），如果并发高、被查表又没索引，可能阻塞其他写入。
更糟的是：若触发器里执行 UPDATE 或 INSERT 操作，会引发嵌套事务行为，在某些隔离级别下触发死锁。MySQL 不允许在触发器中显式开启/提交事务，所以这类操作本质是父语句事务的一部分。
- 尽量避免在触发器中访问非当前表；真有必要，确保被查字段有索引，且查询只读、轻量
- 不要在触发器里调用含写操作的存储过程
- 测试阶段务必用
SHOW ENGINE INNODB STATUS查看锁等待链
MySQL 8.0+ 直接用 CHECK 约束更稳，但要注意这些细节
如果环境允许升级并启用 CHECK，优先选它。语法简洁、无额外执行开销、支持表达式（如 age >= 0 AND age ），且对 <code>INSERT、UPDATE、REPLACE、LOAD DATA 全覆盖。
但别以为写了就万事大吉：
-
CHECK默认不校验已存在数据（即添加约束时不验证历史行），需先清理脏数据再加约束，否则ALTER TABLE ... ADD CHECK会失败 - MySQL 8.0.16–8.0.18 对
CHECK的处理有 bug：某些情况下约束不生效，建议至少用 8.0.19+ - 若表用了分区，
CHECK约束必须与分区表达式兼容，否则CREATE TABLE会报错
触发器和 CHECK 不是非此即彼。复杂逻辑（比如跨表状态校验、调用函数生成动态阈值）仍得靠触发器；简单范围、枚举、非空等，交给 CHECK 更干净。最容易被忽略的是：两者共存时，CHECK 先于触发器执行，但错误信息提示顺序不一定反映实际拦截顺序——出问题时得两边日志一起看。
