应使用逻辑表达式判断跨日非业务时间，如(HOUR(NOW()) >= 22 OR HOUR(NOW())

触发器里怎么判断当前时间是否属于非业务时间

核心是用数据库内置的时间函数获取当前时刻，再和预设的业务时间段做逻辑比较。不同数据库语法略有差异，但思路一致：取出 HOUR(NOW()) 或 EXTRACT(HOUR FROM NOW())，判断是否落在允许范围内。

常见错误是只比小时、忽略日期或时区。比如把“22:00–06:00”简单写成 HOUR(NOW()) BETWEEN 22 AND 6——这永远为假，因为 22 不可能 HOUR(NOW()) >= 22 OR HOUR(NOW()) 。

• MySQL 推荐用 HOUR(NOW())，注意它返回 0–23，不带秒毫秒，够用
• PostgreSQL 用 EXTRACT(HOUR FROM NOW())，结果也是整数，但要注意 NOW() 默认带时区，确保数据库时区和业务时区一致（查 SHOW timezone）
• Oracle 用 TO_NUMBER(TO_CHAR(SYSDATE, 'HH24'))，别用 HH（12 小时制），否则凌晨 1 点会变成 1，和下午 1 点混淆

INSERT/UPDATE/DELETE 触发器里如何中止非法操作

触发器不能直接 “return false”，必须靠抛异常来中断执行。关键是选对异常类型：既要让操作失败，又不能掩盖真实原因。

常见错误是用 RAISE NOTICE（PostgreSQL）或 SELECT 'msg'（MySQL）——这些只是输出，不阻止执行。也有人误用 SIGNAL SQLSTATE '45000' 但没写 MESSAGE_TEXT，导致报错信息空洞，运维排查困难。

• MySQL 5.5+ 必须用 SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = '非业务时间禁止修改数据'
• PostgreSQL 用 RAISE EXCEPTION '非业务时间禁止修改数据'，支持变量拼接，比如 RAISE EXCEPTION '当前时间 % 不在业务时段内', NOW()
• Oracle 用 RAISE_APPLICATION_ERROR(-20001, '非业务时间禁止修改数据')，错误号必须是 -20000 到 -20999 之间

为什么不能只在应用层校验，而要加数据库触发器

触发器是最后一道防线。应用层校验容易绕过：直连数据库的脚本、DBA 临时维护、旧系统未升级、甚至开发本地测试时随手 INSERT 都可能漏掉校验逻辑。

性能影响其实极小——触发器只在 DML 执行时检查几行表达式，不查表、不锁行。但要注意：如果业务时间规则未来要动态配置（比如节假日调整），硬编码在触发器里就难维护，此时应把规则抽到配置表，触发器里 SELECT 查询，不过得加 PRAGMA AUTONOMOUS_TRANSACTION（Oracle）或避免在 MySQL 触发器里查表（会报错）。

• MySQL 触发器内禁止查询当前表（会报 ERROR 1442），所以时间规则只能硬编码或存在另一张配置表（但需确保该表无触发器）
• PostgreSQL 允许触发器内查表，但若配置表被频繁更新，要考虑快照隔离级别下是否读到最新值
• 所有数据库中，触发器不拦截 TRUNCATE（DDL），它绕过 DML 触发器，这点常被忽略

触发器对批量操作和事务的影响

触发器按行触发，不是按语句触发。一个 UPDATE ... WHERE id IN (1,2,3) 会执行三次触发器逻辑，每次单独判断时间。这意味着：如果跨午夜执行（比如 23:59 开始，00:01 结束），前后行可能因系统时钟变化得到不同判断结果——虽然概率低，但理论上存在。

更关键的是事务行为：只要某一行触发了异常，整个语句回滚，哪怕前面几十行已经通过校验。这符合 ACID，但和应用预期可能不一致（比如想让合法数据先落库）。

• 不要指望触发器做“部分成功”，它天生是全有或全无
• 批量导入场景下，建议先用 SELECT 检查当前是否允许操作，再执行 DML；触发器只作为兜底
• MySQL 中，INSERT INTO ... SELECT 这类语句，触发器对每一目标行生效，源表数据不受影响，但目标表插入仍受时间限制

事情说清了就结束。真正难的不是写触发器，而是确认“非业务时间”的定义是否覆盖了所有例外场景——比如紧急发布窗口、灾备切换时段、或者 DBA 备份期间的临时放开策略。这些没法靠代码自动适配，得靠文档和权限流程兜住。