mysql触发器中不能用now()跨行比较时间，因同事务内返回相同时间戳；校验须基于new字段与已有记录时间段比对，并建复合索引；禁止修改其他行、禁用on duplicate key update；跨天班次需改用datetime或拆解逻辑处理。
触发器里不能直接用 NOW() 做跨行时间比较
MySQL 触发器在执行时，NOW()、CURTIME() 等函数每次调用都返回同一毫秒级时间戳，无法反映多条插入记录之间的真实时间差。如果你试图在校验逻辑中依赖 NOW() 判断“新排班是否与已有排班重叠”，会漏掉同事务内多条 INSERT 的冲突——比如批量导入 3 个班次，它们在触发器里看到的 NOW() 完全一样，但实际起止时间可能互相覆盖。
正确做法是：只比对新记录自身的 start_time 和 end_time 与表中**其他已存在记录**的时间段。触发器必须基于新行字段做范围查询，而不是依赖当前时间函数。
- 校验逻辑应写成：
WHERE start_time NEW.start_time AND id != NEW.id - 确保被查表上有复合索引：
CREATE INDEX idx_time_range ON schedule (start_time, end_time)，否则大表下性能急剧下降 - 避免在
BEFORE INSERT中 SELECT 全表——加LIMIT 1并配合EXISTS提前退出
BEFORE INSERT 触发器中禁止修改 NEW 字段以外的数据
你不能在触发器里 UPDATE 其他行来“自动调整冲突班次”，MySQL 会报错 Can't update table 'schedule' in stored function/trigger because it is already used by statement which invoked this stored function/trigger。这是 MySQL 的硬限制，不是权限或事务隔离问题。
这意味着：自动排班校验只能是“守门员”，不是“调度员”。它能做的只有两件事——放行或报错。
- 若发现时间重叠，用
SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'Schedule time conflict detected'中断插入 - 不要尝试在触发器里调用存储过程去修正其他记录，必然失败
- 如果真需要自动腾挪（如把冲突班次顺延 30 分钟），必须把逻辑移到应用层或定时任务中，由外部控制流程
INSERT ... ON DUPLICATE KEY UPDATE 会绕过 BEFORE INSERT 触发器
很多业务用 INSERT ... ON DUPLICATE KEY UPDATE 批量 upsert 排班数据，但这个语法**完全不触发 BEFORE INSERT**，只触发 BEFORE UPDATE（如果存在对应主键/唯一键）。结果就是：时间校验逻辑彻底失效，冲突班次悄无声息地写入。
这不是 bug，是 MySQL 明确文档行为。想守住校验关，必须统一入口：
- 禁用
ON DUPLICATE KEY UPDATE，改用显式INSERT ... SELECT ... WHERE NOT EXISTS (...)模式 - 或在应用层先查再插，把校验逻辑提到 SQL 外部（更可控）
- 如果必须用 upsert，可建一个带校验逻辑的存储过程封装整个流程，但注意存储过程中再嵌套触发器仍受前述限制
跨天班次（如 22:00–06:00）会让时间比较逻辑失效
直接用 start_time NEW.start_time 在跨天场景下会漏判。例如现有班次是 22:00:00 到 06:00:00（隐含次日），而新班次是 04:00:00 到 08:00:00，数值上 04:00:00 成立，但 <code>06:00:00 > 04:00:00 也成立，看起来不重叠——其实重叠了 2 小时。
根本原因是 TIME 类型不带日期，无法表达“次日”语义。解决路径只有两个：
- 把字段类型改为
DATETIME或TIMESTAMP，并约定所有班次按自然日切分（如 22:00–06:00 存为'2024-01-01 22:00:00'和'2024-01-02 06:00:00'） - 若坚持用
TIME，则在校验逻辑中显式拆解跨天情况：IF NEW.start_time > NEW.end_time THEN /* 跨天 */ ... ELSE /* 同天 */ ... - 无论哪种，触发器里的比较条件都必须覆盖两种分支，且索引需适配新类型（
DATETIME索引效果远好于一堆CASE表达式）
触发器能守住单次插入的底线，但排班逻辑的复杂性——跨天、多人共享资源、优先级抢占、节假日偏移——都会快速突破它的能力边界。真正健壮的方案，往往要把核心校验留在应用层，触发器只做兜底防御。
