子查询中用LAG()/LEAD()识别时序断点，本质是计算相邻时间戳差值；必须在最内层子查询输出prev_time和gap_sec，外层才能筛选断点，避免LAG放外层导致NULL或逻辑错误。
子查询里用 LAG() 或 LEAD() 识别断点
时序数据断点，本质是相邻时间戳之间存在空隙。直接在子查询里用窗口函数比先聚合再关联更高效，也避免重复扫描表。关键不是“能不能嵌套”，而是“在哪一层计算差值”——必须在最内层子查询中完成时间差计算，否则外层看不到原始行级的 LAG(time_col) 结果。
常见错误是把 LAG() 放在外层 SELECT 中，但子查询没暴露上一行时间，导致 NULL 或逻辑错乱。正确做法是让内层子查询输出原始字段 + prev_time + gap_sec：
SELECT id, time_col, value,
LAG(time_col) OVER (PARTITION BY id ORDER BY time_col) AS prev_time,
EXTRACT(EPOCH FROM (time_col - LAG(time_col) OVER (PARTITION BY id ORDER BY time_col))) AS gap_sec
FROM raw_series这样外层才能基于 gap_sec > 300（比如5分钟）筛选出断点位置。
用 GENERATE_SERIES() 在子查询中补时间点
PostgreSQL 用户可以直接在子查询里调用 GENERATE_SERIES() 填充缺失时间，但要注意：它不能直接和主表 JOIN，必须先用 LATERAL 或 CTE 拆解。MySQL / SQL Server 用户得换思路——别硬套生成函数，改用递归 CTE 或预建时间维度表关联。
PostgreSQL 示例（内层子查询产出断点区间，外层展开）：
SELECT s.id, gs.ts AS time_col, NULL::float AS value
FROM breaks s,
LATERAL GENERATE_SERIES(
s.prev_time + INTERVAL '1 minute',
s.time_col - INTERVAL '1 minute',
INTERVAL '1 minute'
) AS gs(ts)
WHERE s.gap_sec > 60注意三点：GENERATE_SERIES 的步长必须和原始数据粒度一致；起止时间要严格避开端点（否则会和原数据重复）；LATERAL 是必需的，否则无法引用 s.prev_time。
补全后如何与原数据 UNION ALL 而非 UNION
补齐的行是占位符（value 为 NULL），和原始数据结构一致，但语义不同。用 UNION 会触发去重，而时序数据里完全可能出现相同 (id, time_col) 的多条记录（比如多传感器同秒上报），去重会丢数据。
正确流程是：
- 内层子查询分别产出原始数据集和补全数据集
- 两部分都确保包含相同字段名、类型、顺序
- 用
UNION ALL合并，再在外层统一排序
典型结构：
(SELECT id, time_col, value, 'original' AS src FROM raw_series) UNION ALL (SELECT id, time_col, value, 'filled' AS src FROM filled_points) ORDER BY id, time_col
MySQL 用户绕过无窗口函数的现实方案
MySQL 5.7 不支持 LAG()，8.0+ 虽支持但 GENERATE_SERIES() 依然没有。这时候硬写子查询嵌套容易超内存或超时。更可行的是分两步：先用应用层或临时表算出所有缺失区间（比如 Python 扫一遍时间戳，输出 (id, start_ts, end_ts)），再用 JOIN + 自增数表模拟时间序列填充。
关键约束：
- 不要在单条 SQL 里试图生成几千行补点，MySQL 处理大结果集性能陡降
- 用
JOIN数字表时，务必限制最大跨度，例如nums.n （一天内分钟数） - 补值列建议显式写成
NULL或0，别依赖COALESCE掩盖逻辑缺陷
真正难的不是语法，是判断“该补多少”——断点阈值、填充粒度、是否保留原始 NULL 值，这些业务规则一旦写死在子查询里，后续就很难动态调整。
