应使用 datepart(weekday, getdate()) between 2 and 6 且 datepart(hour, getdate()) >= 9 and datepart(hour, getdate())
SQL Server 中用
DATEPART判断工作日与工作时间触发器本身不区分“用户意图”，只响应
INSERT/UPDATE/DELETE操作。要拦住非工作时间的修改，核心是获取当前服务器时间并校验：是否为周一至周五（DATEPART(WEEKDAY, GETDATE())返回 1=周日、2=周一…7=周六），且小时是否在 9–18 之间（含边界需明确）。注意：GETDATE()返回的是数据库服务器本地时间，不是客户端时间——这点常被忽略，若服务器时区与业务所在地不一致，规则会失效。常见错误是写成
DATEPART(HOUR, GETDATE()) BETWEEN 9 AND 18，但这样会放过 18:00:01 及之后的修改。更稳妥的做法是：DATEPART(HOUR, GETDATE()) >= 9 AND DATEPART(HOUR, GETDATE()) ，再配合分钟判断（如要求严格到 9:00–17:59）。PostgreSQL 触发器中必须用
CURRENT_TIME而非NOW()PostgreSQL 的
NOW()返回带时区的时间戳（TIMESTAMP WITH TIME ZONE），而CURRENT_TIME直接返回不带日期的本地时间（TIME WITHOUT TIME ZONE），更适合做小时/分钟比对。若误用NOW()，还得额外EXTRACT(HOUR FROM NOW())，且可能因时区转换出错。实操建议：
- 用
EXTRACT(DOW FROM CURRENT_TIMESTAMP)判断星期几（0=周日，1=周一…6=周六）- 用
CURRENT_TIME BETWEEN '09:00' AND '17:59'判断时间段，注意字符串格式必须匹配TIME类型- 触发器函数返回
NULL可中止操作（BEFORE触发器），但需确保函数定义为RETURNS TRIGGERMySQL 触发器里不能直接调用
NOW()做条件判断？可以调用，但 MySQL 在
BEFORE UPDATE或BEFORE INSERT触发器中禁止修改NEW行以外的数据，而时间判断本身不违反这条。真正容易踩的坑是：MySQL 默认不支持在触发器中使用SIGNAL抛出错误（5.5+ 支持，但部分旧部署仍禁用）。若无法用SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'Off-hours edit denied';，就得退回到“静默丢弃”——即设NEW.col = OLD.col强制回滚字段值，但这会让应用层误以为更新成功。更可靠的做法：
- 确认 MySQL 版本 ≥ 5.5 且
sql_mode包含STRICT_TRANS_TABLES- 用
DAYOFWEEK(NOW())（1=周日，2=周一…7=周六）配合HOUR(NOW())- 避免用
BETWEEN，改用HOUR(NOW()) >= 9 AND HOUR(NOW()) ，再加 <code>MINUTE(NOW()) （冗余但显式）所有数据库都绕不开的权限与调试盲区
触发器由执行 SQL 的用户身份触发，但其代码运行在数据库上下文，不受应用层 session 时区影响——所以务必确认数据库服务器系统时区已设为业务所在时区（如
Asia/Shanghai），而不是默认的 UTC。Linux 上可通过timedatectl status查，Windows 看服务属性。另一个关键点：DBA 或具有
TRIGGER权限的账号创建的触发器，普通用户无法看到或调试。一旦规则生效后出现“莫名更新失败”，排查路径只能是查sys.triggers（SQL Server）、pg_trigger（PostgreSQL）或information_schema.TRIGGERS（MySQL），再结合错误日志定位。别指望应用日志里会有触发器拦截的提示。
怎样编写SQL触发器来防止用户在非工作时间修改数据库？
云伟大大_9526
2026-06-09
193人浏览
原创
