核心条件是NOT (A_end

SQL判断两个日期区间是否重叠的核心条件是什么

直接用 NOT (A_end ，等价于 <code>A_start 。这是唯一可靠、无边界遗漏的写法，所有其他变形（比如只比开始时间或只比结束时间）在端点相接（如 A_end = B_start）时都会出错。

MySQL/PostgreSQL中写WHERE子句查重叠记录的实际例子

假设表 events 有字段 start_at 和 end_at，要查和给定区间 '2024-03-10' 到 '2024-03-15' 有交集的所有行：

SELECT * FROM events
WHERE start_at <= '2024-03-15' AND '2024-03-10' <= end_at;

注意：左右两侧的比较对象不能互换位置——左侧必须是待查记录的 start_at 与输入区间的右端，右侧是输入区间的左端与待查记录的 end_at。顺序错会导致漏数据。

• 如果字段含时分秒，确保输入值也带时间（如 '2024-03-10 00:00:00'），否则可能因隐式截断丢掉当天首尾记录
• 若字段允许 NULL，需额外加 start_at IS NOT NULL AND end_at IS NOT NULL，否则 NULL 参与比较结果恒为 UNKNOWN，整行被过滤
• PostgreSQL 支持 OVERLAPS 操作符（(start_at, end_at) OVERLAPS ('2024-03-10', '2024-03-15')），但 MySQL 不支持，跨库慎用

为什么用 BETWEEN 或 IN 做区间交集判断会失败

BETWEEN start AND end 是单点归属判断，不是区间关系运算。它只能回答“某个时间点是否落在某区间内”，无法表达“两个区间是否交叉”。常见错误写法：

-- ❌ 错误：这只是在查事件是否完全包裹输入区间，漏掉大量部分重叠情况
WHERE '2024-03-10' BETWEEN start_at AND end_at 
  AND '2024-03-15' BETWEEN start_at AND end_at

这种写法只命中那些把整个输入区间完全包含在内的记录，而现实中大部分重叠是“你头我尾”或“你尾我头”式交叉，必须回归两端双向约束逻辑。

索引能否加速这类查询？关键看字段和条件写法

只有当查询能利用到复合索引的最左前缀时，性能才明显提升。例如建了 INDEX idx_date (start_at, end_at)，那么以下写法可走索引：

WHERE start_at <= '2024-03-15' AND end_at >= '2024-03-10'

但反过来写（end_at >= ... AND start_at ）在某些旧版 MySQL 中可能无法触发索引下推，建议保持 <code>start_at 在前的顺序。另外，如果表里存在大量长期未结束的记录（end_at 为极大值或 NULL），这个条件的选择性会变差，实际执行计划需用 EXPLAIN 验证。

端点是否闭合、时区是否统一、字段类型是 DATE 还是 TIMESTAMP——这些细节不显眼，但任何一个出问题，交集结果就不可信。