查表内自身重叠记录用自连接+重叠条件直接定位冲突行，关键在于识别互相冲突的具体记录而非仅判断存在性；需加e1.id != e2.id避免自匹配，重叠条件固定为e1.end_time >= e2.start_time and e2.end_time >= e1.start_time，null字段须显式过滤，业务插入前校验应使用原子化insert...select+not exists防竞态。
查表内是否存在自身重叠记录
直接用自连接 + 重叠条件就能定位冲突行，不用先写函数或建临时表。关键不是“有没有重叠”，而是“哪几条在互相打架”。
- 必须加
e1.id != e2.id，否则每条记录都会和自己匹配一次 - 重叠条件固定写成
e1.end_time >= e2.start_time AND e2.end_time >= e1.start_time，顺序不能反——它对应数学上最简的交集定义，端点相接（如 A_end = B_start）也算重叠 - 字段含 NULL 时，整行比较结果为 UNKNOWN，会被 WHERE 过滤掉，所以得提前补：
e1.start_time IS NOT NULL AND e1.end_time IS NOT NULL AND e2.start_time IS NOT NULL AND e2.end_time IS NOT NULL - 如果只关心“是否存在重叠”，外层套
EXISTS比SELECT *更轻量；若要导出所有冲突对，加DISTINCT防止 (A,B) 和 (B,A) 重复出现
用嵌套查询做插入前校验
业务系统在插入新日期区间前，常需确认不与现有数据冲突。这时不能靠应用层查完再插（竞态风险），得用原子化 SQL 实现“检查+拒绝”逻辑。
- 典型写法是把校验逻辑包进
INSERT ... SELECT的子查询里，例如：INSERT INTO events (start_at, end_at, title) SELECT '2024-07-01', '2024-07-05', '会议' WHERE NOT EXISTS ( SELECT 1 FROM events WHERE end_at >= '2024-07-01' AND start_at
-
NOT EXISTS比NOT IN安全：后者遇子查询返回 NULL 就整个条件失效，前者只看是否存在匹配行 - 注意子查询里的条件方向：新记录的
start_at要和老记录的end_at比，新记录的end_at要和老记录的start_at比——漏掉任一端，就会放过部分重叠 - MySQL 8.0+ 可用
INSERT ... ON DUPLICATE KEY UPDATE配合唯一约束，但日期区间无法直接建唯一索引，仍得靠逻辑校验
嵌套查询中时间精度与类型对齐
重叠判断失败，十次有八次是因为字段类型或精度没对齐，不是逻辑写错。
- DATETIME 和 TIMESTAMP 在某些 MySQL 版本下隐式转换会截断毫秒，导致
'2024-07-01 10:00:00.123'和'2024-07-01 10:00:00'被判为不重叠——统一用CAST(x AS DATETIME(3))对齐精度 - 字符串类型存储时间（如
VARCHAR）绝对要避免，字典序比较会崩：'10:00' > '9:59' 成立，但 '2024-1-1' - 跨时区场景下，
start_at和end_at必须同为 UTC 或同为本地时间，混用会导致凌晨时段大量误判 - PostgreSQL 的
tsrange类型可简化逻辑：(start_at, end_at) && ('2024-07-01', '2024-07-05')，但 MySQL 不支持，嵌套查询里还是得手写两端比较
性能卡点：索引怎么建才真正生效
重叠查询慢，往往不是逻辑问题，而是索引没被用上。复合索引的字段顺序和 WHERE 条件顺序必须咬合。
- 建索引优先按
start_at在前、end_at在后：CREATE INDEX idx_period ON events (start_at, end_at)——因为查询条件里start_at 是范围扫描起点，<code>end_at >= ?是过滤项 - 如果 WHERE 写成
end_at >= ? AND start_at ，旧版 MySQL 可能只用上 <code>end_at字段的索引，start_at变成全表过滤 - 高基数字段（如
user_id）应前置到复合索引最左，再接时间字段，例如：(user_id, start_at, end_at)，这样先按用户筛，再查时间重叠，比全表扫快几个数量级 - EXPLAIN 看执行计划时，重点关注
key是否命中索引、rows是否明显下降——别只看“是否用索引”，要看“用了多少行”
