lag()无法可靠识别重叠时间段，因其仅获取相邻行单点时间，不能判断任意两区间是否重叠；正确方法是用自连接或overlaps运算符进行二元区间比较，如postgresql用(t1.start_time,t1.end_time) overlaps (t2.start_time,t2.end_time)，mysql用t1.start_time t2.start_time。
直接用 LAG() 无法可靠识别重叠时间段——它只能拿到前一行时间，但重叠是区间关系，不是单点顺序问题。真正该用的是区间逻辑判断或 OVERLAPS 运算符。
为什么 LAG() 单独用会误判重叠
LAG() 只能取上一条记录的某个字段值，比如上一次的 start_time 或 end_time，但它不理解“当前段是否和前面某一段重叠”，只看到紧邻的前一段。如果数据没按起止时间全序排列，或者重叠发生在非相邻行之间（如第1行和第5行重叠），LAG() 完全捕获不到。
- 常见错误现象：
end_time > LAG(start_time)被当成重叠条件，结果把所有后一段比前一段开始得晚的都标成“重叠”，实际可能完全分离 - 真实重叠必须同时满足：
current_start previous_start，而LAG()拿不到previous_end和current_start的组合比较能力 - 若原始数据未按
start_time排序，LAG()返回的“上一行”可能是任意记录，逻辑彻底失效
正确做法：用自连接或 OVERLAPS 判断任意两段是否重叠
重叠是二元关系，必须在行与行之间做笛卡尔/半连接比较。窗口函数解决不了，得靠 JOIN 或专用运算符。
- PostgreSQL 直接用：
(t1.start_time, t1.end_time) OVERLAPS (t2.start_time, t2.end_time)，注意要加t1.id != t2.id避免自比 - MySQL / SQL Server / 大多数引擎用等价逻辑：
t1.start_time t2.start_time - 要查“谁和谁重叠”，必须自连接：
FROM events t1 JOIN events t2 ON t1.id （避免重复配对） - 性能关键：给
start_time和end_time建复合索引，例如CREATE INDEX idx_time_range ON events(start_time, end_time)
如果非要结合 LAG()，只适合预筛选+辅助验证
LAG() 不是主武器，但在特定前提下可作轻量级前置过滤：比如已知数据严格按 start_time 排序，且业务上只关心“是否被紧邻前一段覆盖”，这时可用 LAG() 快速扫一遍。
- 适用场景：会议室预订系统中，新预约是否紧挨着上一个结束时间太近（如
- 写法示例（PostgreSQL）：
start_time - 必须加
ORDER BY start_time，否则无意义；若存在NULL的end_time，需用COALESCE(end_time, NOW())防崩 - 这不能替代真正的重叠检测，只是降低后续自连接的数据量——仍需对命中行再跑一遍完整区间判断
最容易被忽略的边界：NULL、开区间、时区
真实数据里，end_time 为 NULL 表示“至今有效”，这种开区间必须显式处理，否则 OVERLAPS 或自连接会跳过。
- PostgreSQL 中
(s1, NULL) OVERLAPS (s2, e2)返回NULL，不是TRUE，得改写为：s1 s2 - MySQL 没有
OVERLAPS，必须手写等价逻辑，并统一用IFNULL(end_time, NOW())替换空值 - 所有时间字段必须转成同一时区再比，比如
start_time AT TIME ZONE 'UTC'，否则夏令时切换点附近会出现虚假重叠
