应在BEFORE INSERT/UPDATE触发器中用IF判断字段范围，不满足则抛错；需显式处理NULL、多字段关联校验及数据类型隐式转换；MySQL 8.0.16+优先用CHECK约束，5.7或动态逻辑才用触发器。
触发器里怎么写数值范围校验逻辑
直接在 BEFORE INSERT 或 BEFORE UPDATE 触发器中用 IF 判断字段值是否超出预设范围，不满足就抛出错误。MySQL 用 SIGNAL SQLSTATE '45000'，PostgreSQL 用 RAISE EXCEPTION，SQL Server 用 THROW。
- 必须用
BEFORE触发器——AFTER已经写入，拦不住越界 - 对
NULL要显式判断：比如IF NEW.age IS NOT NULL AND (NEW.age 150) THEN ... - 别只校验单个字段：如果
discount_rate要求在 0–1 之间，记得同时检查discount_amount是否与之冲突 - MySQL 5.7+ 才支持
SIGNAL；低版本只能靠INSERT INTO nonexistent_table强制报错，不推荐
触发器校验 vs CHECK 约束哪个更可靠
CHECK 约束语义清晰、性能好，但 MySQL 在 8.0.16 之前完全不支持（只解析不执行），PostgreSQL 和 SQL Server 支持较好。触发器是跨版本兜底方案，但代价是额外执行开销和维护复杂度。
- MySQL 8.0.16+ 优先用
CHECK：例如ALTER TABLE users ADD CONSTRAINT chk_age CHECK (age BETWEEN 0 AND 150) - MySQL 5.7 或需要动态逻辑（如“金额不能超过用户余额”）时，才必须用触发器
- 触发器无法阻止通过
LOAD DATA INFILE或INSERT ... SELECT绕过校验——这些操作可能跳过触发器 - 某些 ORM（如 Django 的
bulk_create）默认不触发触发器，得确认框架行为
常见越界误判场景和修复方式
看似简单的范围检查，常因数据类型隐式转换、浮点精度、时区或默认值干扰而失效。
-
DECIMAL(5,2)字段存999.99没问题，但若应用层传字符串"1000.00"，触发器里用CAST(NEW.price AS DECIMAL)可能截断或报错，建议先用REGEXP验证格式 - 时间字段如
expire_at要求 ≥NOW()，但触发器里用NOW()在事务中可能被快照固化，改用SYSDATE()（MySQL）或CURRENT_TIMESTAMP（PG）更准 - 插入时未指定字段，触发器读
NEW.column是NULL，但业务上该字段有默认值——得在触发器里先查表默认值或硬编码兜底逻辑 - 整数溢出：
TINYINT UNSIGNED最大 255，但触发器里写IF NEW.score > 255会漏掉插入256导致自动转成0的静默截断，必须配合列定义一起看
触发器调试和上线前必须验证的三件事
线上加触发器不是“写完就跑”，容易因权限、隔离级别或并发导致行为异常。
- 用
SHOW TRIGGERS LIKE 'table_name'（MySQL）或\df+ function_name（PG）确认触发器已启用且定义无语法错误 - 手动执行一次
INSERT和UPDATE，观察是否真报错，错误信息是否明确（比如包含字段名和允许范围） - 模拟并发插入：两个会话同时向同一张表插入越界值，确认不会出现“一个成功一个失败”却没报错的假阴性——某些数据库在
READ COMMITTED下可能缓存旧值
最麻烦的不是写错逻辑，而是触发器依赖了另一个表的当前状态（比如查余额），而那个表本身也在被更新——这种跨表校验极易引发死锁或幻读，尽量拆到应用层做最终一致性校验。
