本文详解如何用简洁可靠的 sql 条件判断时间区间是否重叠，特别支持“首尾相接”（abutting）——即新事件的开始时间等于已有事件的结束时间，或反之——这类合法边界情况不视为冲突。
本文详解如何用简洁可靠的 sql 条件判断时间区间是否重叠，特别支持“首尾相接”（abutting）——即新事件的开始时间等于已有事件的结束时间，或反之——这类合法边界情况不视为冲突。
在开发工时管理系统（Timesheet App）时，确保时间记录不发生逻辑冲突是核心数据完整性要求。一个常见但易错的需求是：允许时间区间首尾相接（如 A 结束于 2022-03-22 21:00:00，B 开始于 2022-03-22 21:00:00），但严格禁止任何实质性重叠（如 B 开始于 2022-03-22 20:59:00）。
许多开发者尝试用 BETWEEN 或多层 OR 组合（如检查“部分重叠于开头/结尾”“完全包含”等）来覆盖所有重叠情形，但这类写法不仅冗长、易漏，更关键的是——它们天然将相等时间点判定为重叠，从而错误拒绝合法的 abutting 场景。例如：
-- ❌ 错误示例：此条件会把 (21:00, 22:00) 与 (21:00, 22:38) 判定为重叠（因 end_event >= start_event） WHERE '2022-03-22 21:00:00' BETWEEN start_event AND end_event OR '2022-03-22 22:00:00' BETWEEN start_event AND end_event
✅ 正确解法：基于“开区间重叠”的数学本质
两个时间区间 [d1, d2] 和 [s, e] 发生实质性重叠（非仅端点接触）当且仅当：
新事件的开始时间早于已有事件的结束时间，且 新事件的结束时间晚于已有事件的开始时间。
用不等式表达即：
d1 s
该条件天然排除了端点相等的情形：
- 若 d1 == e（新开始 = 旧结束）→ d1
- 若 d2 == s（新结束 = 旧开始）→ d2 > s 为假 → 不触发重叠
因此，它完美契合“允许 abutting，拒绝 overlap”的业务规则。
? 实际 SQL 应用示例
假设你要插入新记录：start_event = '2022-03-22 21:38:00', end_event = '2022-03-22 22:00:00'，需先检查用户 ID=4 的历史记录是否存在冲突：
SELECT id, start_event, end_event FROM timesheets WHERE user_id = 4 AND '2022-03-22 21:38:00' < end_event AND '2022-03-22 22:00:00' > start_event;
✅ 若查询返回空结果 → 无重叠，可安全插入；
❌ 若返回任意行 → 存在实质性重叠，应拒绝提交。
? 注意：该逻辑成立的前提是时间字段类型为 DATETIME 或 TIMESTAMP，且数据库时区配置一致。若使用 DATE 类型，需确保精度满足业务需求（如需精确到分钟，勿用 DATE）。
⚠️ 常见陷阱与最佳实践
- 避免 BETWEEN：BETWEEN a AND b 是闭区间（包含端点），无法区分 == 和 >，违背 abutting 允许原则。
- 警惕 NULL 值：若 start_event 或 end_event 可为空，需额外处理（如 AND start_event IS NOT NULL AND end_event IS NOT NULL）。
-
索引优化：为提升查询性能，在 (user_id, start_event, end_event) 上创建复合索引：
CREATE INDEX idx_user_time ON timesheets (user_id, start_event, end_event);
- 应用层校验：SQL 检查应在事务内执行，并配合应用层逻辑（如检查 start_event
✅ 总结
一句精简的 WHERE d1 start_event 即可稳健解决时间重叠检测问题，既杜绝冗余逻辑，又精准支持业务所需的“端点相接即合法”语义。将其嵌入插入前的预检查询，即可构建高可靠的时间表数据约束体系。
