必须用BEFORE UPDATE触发器配合IF判断+ SIGNAL中断，例如：IF WEEKDAY(NOW()) BETWEEN 0 AND 4 AND HOUR(NOW()) BETWEEN 18 AND 21 THEN SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'Updates blocked Mon-Fri 18:00-22:00'; END IF;
触发器里怎么判断当前时间是否在禁止修改时段
MySQL 触发器本身不能直接用 NOW() 或 CURTIME() 做条件拦截（因为触发器执行时语句已解析，SELECT 或函数调用需显式写入逻辑），但可以结合 IF + 时间函数实现硬性拒绝。关键不是“阻止时间流逝”，而是“在 BEFORE UPDATE 里主动报错”。
常见错误是试图用 WHERE 过滤或只查不拦——触发器没返回值，不抛异常就等于放行。
- 必须用
IF判断时间范围，例如：禁止周一至周五 18:00–22:00 修改 - 推荐用
HOUR(NOW())和WEEKDAY(NOW())（注意：周一是 0，周日是 6）组合判断 - 一旦命中禁止时段，必须用
SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'Modification not allowed during maintenance window'中断操作 - 避免用
SELECT ... INTO赋值再判断——多一次查询开销，且可能被优化掉
BEFORE UPDATE 触发器中 SIGNAL 的实际写法
SIGNAL 是 MySQL 5.5+ 强制中断执行的唯一可靠方式，ROLLBACK 在触发器里无效，LEAVE 也不适用。下面是一个可直接创建的示例：
DELIMITER $$
CREATE TRIGGER tr_prevent_offhours_update
BEFORE UPDATE ON orders
FOR EACH ROW
BEGIN
IF WEEKDAY(NOW()) BETWEEN 0 AND 4
AND HOUR(NOW()) BETWEEN 18 AND 21 THEN
SIGNAL SQLSTATE '45000'
SET MESSAGE_TEXT = 'Updates blocked Mon-Fri 18:00-22:00';
END IF;
END$$
DELIMITER ;
注意：BETWEEN 18 AND 21 表示 18:00、19:00、20:00、21:00 四个整点小时，若需包含 21:59，应改用 HOUR(NOW()) >= 18 AND HOUR(NOW()) 。
- 触发器名必须唯一，且不能与表名冲突（如
orders_before_update比tr_orders更易维护） -
SQLSTATE '45000'是用户自定义异常的标准码，应用层捕获时可据此区分业务限制和数据库错误 - 不要在触发器里写
INSERT INTO log_table—— 可能引发递归或死锁
跨天时段（如 22:00–06:00）怎么安全判断
跨天逻辑容易漏掉边界，比如 22:00–06:00 实际是“当天 22:00 后”或“次日 06:00 前”，不能简单用 BETWEEN。正确做法是拆成两个条件并用 OR 连接：
- 方案一（推荐）：
(HOUR(NOW()) >= 22) OR (HOUR(NOW()) - 方案二（更严谨）：加上日期偏移判断，但通常没必要——只要服务器时区稳定，小时判断已足够
- 务必测试临界点：21:59、22:00、05:59、06:00 —— 尤其注意
不含 6:00，符合“06:00 解除限制”的预期 - 如果业务要求精确到分钟（如 22:30–05:45），改用
TIME(NOW())配合字符串比较：TIME(NOW()) >= '22:30:00' OR TIME(NOW())
触发器限制修改的隐蔽风险
这个方案看似简单，但上线前必须确认三件事：时区、权限、性能影响。
- MySQL 服务器时区必须和业务预期一致（
SELECT @@time_zone），否则NOW()返回的是系统时区时间，不是你认为的“本地时间” - 创建触发器需要
TRIGGER权限，且对目标表有ALTER权限；普通应用账号无需该权限，但部署账号必须有 - 每个 UPDATE 都会执行触发器逻辑，哪怕没命中禁止时段——函数调用开销极小，但高并发下仍建议压测验证
- 最易忽略的一点：触发器只拦 DML，拦不住
DELETE + INSERT绕过、拦不住直接改磁盘文件、也拦不住从备份恢复数据
真正敏感的数据时段控制，应配合应用层校验 + 数据库审计日志 + 定期巡检，触发器只是最后一道轻量防线。
