核心是建promotion_schedule表并用now()动态查询，禁止硬编码日期；mysql用signal报错，postgresql需先建函数再绑定，且两者均不支持触发器内dml。
触发器里怎么判断当前是否处于促销期间
核心是让触发器能动态识别「促销期间」，不能硬编码日期范围。推荐在数据库中建一张 promotion_schedule 表，字段至少包含 start_time、end_time、status（比如 'active'），并确保有有效索引。
触发器内用子查询检查：当前时间是否落在任一 active 的促销区间内。注意使用 NOW()（MySQL）或 CURRENT_TIMESTAMP（PostgreSQL/SQL Server），避免用客户端传入的时间——那不可信。
常见错误：直接写 WHERE '2024-06-01' BETWEEN start_time AND end_time —— 这会锁表或全表扫描，且无法利用索引；正确写法是 WHERE NOW() >= start_time AND NOW() ，配合复合索引 <code>(status, start_time, end_time)。
UPDATE/DELETE 时如何拦截非正常库存调整
触发器需作用于 inventory 表的 BEFORE UPDATE 和 BEFORE DELETE 事件。重点不是禁止所有变更，而是拦截「非业务系统发起的、无合理依据的调整」。
实操建议：
- 检查
NEW.quantity变化量是否超出预设阈值（比如单次变动 > 500 且非由订单履约系统标记） - 验证
NEW.updated_by字段是否属于白名单应用标识（如'order-service'、'replenish-job'），拒绝'admin-ui'或空值 - 若促销期间，禁止
SET quantity = ...类绝对赋值，只允许通过quantity = quantity + ?形式相对调整（便于审计溯源）
别忽略 OLD.quantity 和 NEW.quantity 都为 NULL 的边界情况——某些 ORM 会清空字段，这可能被误判为恶意清零。
MySQL vs PostgreSQL 触发器写法差异要点
MySQL 用 CREATE TRIGGER ... BEFORE UPDATE ON inventory FOR EACH ROW，逻辑写在 BEGIN ... END 块中，用 IF EXISTS (SELECT 1 FROM promotion_schedule WHERE ...) 判断促销状态；报错必须用 SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'Inventory lock during promotion';。
PostgreSQL 更严格：需先创建函数（CREATE OR REPLACE FUNCTION prevent_inventory_tamper()），再绑定触发器；条件判断用 PERFORM 1 FROM promotion_schedule WHERE ...；抛异常用 RAISE EXCEPTION 'Inventory update blocked'。
关键区别：
- MySQL 不支持在触发器里调用存储过程返回结果集，PostgreSQL 支持但性能敏感
- PostgreSQL 的
NEW是行级记录，修改字段要写NEW.quantity := ...；MySQL 直接赋值SET NEW.quantity = ... - 两者都不允许在触发器里做 DML 操作（如 INSERT 日志表），除非用自治事务（PG 14+ 支持，MySQL 不支持）
为什么不能只靠触发器，还得加应用层校验
触发器是最后一道防线，但存在明显盲区：它不拦住 TRUNCATE TABLE inventory，不拦住 DROP COLUMN quantity，也不拦住备份恢复后直接改数据文件这种操作。
真正有效的防护是分层：
- DBA 层：回收普通账号的
ALTER、TRUNCATE、DROP权限，只保留SELECT/INSERT/UPDATE/DELETE - 应用层：所有库存变更接口必须带
x-operation-source: order-service头，并校验签名；促销期间自动拒绝非白名单来源请求 - 审计层：用
AFTER UPDATE触发器把每次变更写入inventory_audit表，含 IP、应用名、SQL 摘要（截取前 200 字符）
最易被忽略的一点：触发器本身没权限控制——只要用户能执行 UPDATE，就能触发它；所以 DEFINER 权限设置不当（比如用 root@% 定义）反而会扩大攻击面。应始终用最小权限账号（如 inv_trig@localhost）定义触发器。
