重叠判断的正确WHERE条件是：end_time > '2024-05-01 09:00:00' AND start_time < '2024-05-01 11:30:00'；需为start_time和end_time建立联合索引以保障性能。
判断两个时间区间是否重叠的SQL逻辑
MySQL里没有内置的“区间重叠判断函数”，但用反向思维最可靠：两个区间不重叠，只有两种情况——A完全在B左边，或A完全在B右边；其余情况就是重叠。所以直接写 NOT (end1 ，等价于 <code>end1 > start2 AND end2 > start1。
实际查询时怎么写WHERE条件
假设你有一张表 events，字段是 start_time 和 end_time（类型为 DATETIME 或 TIMESTAMP），想查出和给定区间 '2024-05-01 09:00:00' 到 '2024-05-01 11:30:00' 重叠的所有记录：
SELECT * FROM events WHERE end_time > '2024-05-01 09:00:00' AND start_time < '2024-05-01 11:30:00';
注意这里用的是严格不等号：end_time > 给定开始 且 start_time 。如果允许端点相接（比如一个结束=另一个开始算不重叠），这个写法刚好符合常规业务定义。
- 别写成
BETWEEN——它包含端点，容易把“紧邻”误判为重叠 - 确保字段和参数类型一致，否则隐式转换可能导致索引失效
- 如果字段可能为
NULL，记得加IS NOT NULL过滤，否则整行会被跳过
用变量或参数动态传入区间时的注意事项
在存储过程或应用层拼接SQL时，常见坑是时间格式不对或时区错乱：
- MySQL默认按会话时区解析字符串字面量，
SET time_zone = '+08:00'要提前设好 - 用
STR_TO_DATE()显式转换用户输入的字符串，避免因格式不匹配返回NULL - 如果用预处理语句（如
PREPARE），参数必须是合法的DATETIME值，不能传字符串让MySQL自己猜 - 考虑夏令时边界（如欧洲某些地区），用
TIMESTAMP类型比DATETIME更稳妥
性能优化：为什么一定要加联合索引
只对 start_time 或只对 end_time 加单列索引，MySQL优化器大概率无法高效执行重叠查询。因为条件涉及两个字段的范围扫描，必须建联合索引：
CREATE INDEX idx_time_range ON events (start_time, end_time);
这个顺序很重要：先按 start_time 排序，再按 end_time，才能支撑 start_time ? 这类双边界查询。实测在百万级数据上，没索引可能秒变几秒，有索引保持毫秒级。
边界情况容易被忽略：当区间极短（比如几秒）而数据分布稀疏时，即使有索引，也可能因选择性差导致全索引扫描——这时候得结合业务补上其他高区分度字段做覆盖索引。
