判断工作时间需用数据库函数提取小时和星期并组合逻辑：MySQL用HOUR(NOW())和WEEKDAY(NOW())，PostgreSQL用EXTRACT(HOUR FROM NOW())和EXTRACT(DOW FROM NOW())，SQL Server用DATEPART(HOUR, GETDATE())和DATEPART(WEEKDAY, GETDATE())，所有计算基于服务器本地时区。
触发器里怎么判断当前时间是否在工作时间内
核心是用数据库内置的时间函数提取小时和星期，再组合逻辑表达式。MySQL 用 HOUR(NOW()) 和 WEEKDAY(NOW())（周一为 0，周日为 6），PostgreSQL 用 EXTRACT(HOUR FROM NOW()) 和 EXTRACT(DOW FROM NOW())（周日为 0，周六为 6），SQL Server 用 DATEPART(HOUR, GETDATE()) 和 DATEPART(WEEKDAY, GETDATE())（取决于 SET DATEFIRST）。注意：所有时间都按数据库服务器本地时区计算，不是应用层传入的时间。
INSERT/UPDATE 触发器中阻止非工作时间写入的典型写法
以 MySQL 为例，在 BEFORE INSERT 和 BEFORE UPDATE 触发器中做校验，不满足条件就抛出错误中断操作：
DELIMITER $$
CREATE TRIGGER trg_block_offhours_insert
BEFORE INSERT ON orders
FOR EACH ROW
BEGIN
IF WEEKDAY(NOW()) IN (5,6) OR HOUR(NOW()) NOT BETWEEN 9 AND 17 THEN
SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'Write operations are only allowed on weekdays 09:00–17:00';
END IF;
END$$
DELIMITER ;
- 用
WEEKDAY(NOW()) IN (5,6)排除周六（5）、周日（6）；若想包含周五下班后，需额外限定HOUR(NOW()) 17 -
SIGNAL是 MySQL 5.5+ 的标准中断方式，旧版本可用INSERT INTO ... SELECT 1/0触发除零错误（不推荐） - PostgreSQL 需用
RAISE EXCEPTION，SQL Server 用THROW或RAISERROR
为什么不能只靠应用层控制，还得加数据库触发器
应用层时间校验容易绕过：运维直连数据库执行脚本、DBA 手动修复数据、其他接入系统（如 ETL 工具、BI 查询引擎）可能跳过业务逻辑。触发器是最后一道防线，只要 DML 走 SQL 接口就会被拦截。
- 但触发器不拦截
LOAD DATA INFILE（MySQL）、COPY（PostgreSQL）等批量导入命令——这些属于“非标准 DML”，需额外限制权限或改用带校验的存储过程封装 - 触发器本身有性能开销，高频写入表慎用；可考虑只对关键业务表（如
payments、user_profiles）启用 - 测试时务必验证跨时区场景：如果数据库设为 UTC，而业务要求按北京时间（UTC+8）判断，则需用
CONVERT_TZ(NOW(), '+00:00', '+08:00')转换后再取小时
常见报错和调试盲点
最常遇到的是时间函数返回值与预期不符，导致“明明是工作时间却报错”或“非工作时间没拦住”：
-
WEEKDAY()和DAYOFWEEK()返回值相反（MySQL），混用会逻辑翻转 - PostgreSQL 的
EXTRACT(DOW FROM NOW())周日=0，但很多业务规则按“周一至周五”理解，直接写NOT IN (0,6)会误拦周一 - 触发器中调用
NOW()/CURRENT_TIMESTAMP是语句开始时间，不是行处理时间；批量插入多行时，所有行共享同一个时间戳，这点没问题，但别误以为能逐行取不同时间 - MySQL 8.0+ 默认开启
sql_mode=STRICT_TRANS_TABLES，SIGNAL错误能正常抛出；低版本若模式宽松，可能静默失败，需检查SHOW VARIABLES LIKE 'sql_mode';
真正难搞的是节假日——触发器没法自动识别法定假日，得额外维护一张 holidays 表并关联查询，否则春节初一凌晨三点照样放行。这已经超出纯时间判断范畴了。
