join无法完成时序插值补全，因其仅匹配现有行、不生成新时间点或计算中间值；必须先构造完整时间轴（如generate_series或递归cte），再通过窗口函数或自连接实现插值。
为什么直接用 JOIN 无法完成时序插值补全
JOIN 本身只是按条件匹配行，不生成新时间点、不计算中间值。你试图用 LEFT JOIN 或 INNER JOIN 连接原始时序表和一个“完整时间序列”表，只能对已有时间戳做对齐，但缺失的时间点（比如某天没记录）不会自动出现——除非你先显式构造出所有目标时间点。
常见错误现象：SELECT * FROM sensor_data LEFT JOIN time_grid ON sensor_data.ts = time_grid.ts 看似合理，结果却仍是空行或 NULL，因为 time_grid 没覆盖你要插值的区间，或根本没建出来。
- 必须先用递归 CTE（PostgreSQL/SQL Server）、
generate_series()（PostgreSQL）、或日期循环（MySQL 8.0+ 的WITH RECURSIVE）生成连续时间轴 - JOIN 只负责把原始数据“挂”到这个轴上，后续插值逻辑（线性、前向、均值）得靠窗口函数或自连接实现
- 不同数据库对时间序列生成的支持差异极大：SQLite 不原生支持递归或序列生成；MySQL 在 8.0 前几乎无法干净构造等间隔时间点
PostgreSQL 中用 generate_series + LAG/LEAD 做线性插值
这是目前最简洁可行的路径：用 generate_series() 构造时间网格，再用窗口函数找前后最近的有效观测值，最后用比例公式算中间值。
WITH grid AS (
SELECT ts::TIMESTAMP FROM generate_series(
'2024-01-01'::TIMESTAMP,
'2024-01-10'::TIMESTAMP,
'1 day'::INTERVAL
) AS ts
),
filled AS (
SELECT
g.ts,
s.value,
LAG(s.value) OVER (ORDER BY g.ts) AS prev_val,
LEAD(s.value) OVER (ORDER BY g.ts) AS next_val,
LAG(s.ts) OVER (ORDER BY g.ts) AS prev_ts,
LEAD(s.ts) OVER (ORDER BY g.ts) AS next_ts
FROM grid g
LEFT JOIN sensor_data s ON g.ts = s.ts
)
SELECT
ts,
COALESCE(
value,
prev_val + (next_val - prev_val) * EXTRACT(EPOCH FROM (ts - prev_ts)) / EXTRACT(EPOCH FROM (next_ts - prev_ts))
) AS interpolated_value
FROM filled
WHERE prev_val IS NOT NULL AND next_val IS NOT NULL;
注意：这个写法要求每个缺失点前后都至少有一个有效值；如果开头/结尾断档，COALESCE 会保留 NULL，需额外用 FIRST_VALUE() IGNORE NULLS 或 LAST_VALUE() 处理边界。
MySQL 8.0+ 中用 WITH RECURSIVE 模拟时间轴并自连接求邻近点
MySQL 没有 generate_series()，但可用递归 CTE 构造时间点；插值部分不能依赖 LAG/LEAD 直接跨缺失段，得靠自连接找“上一个有值的时间”和“下一个有值的时间”。
- 递归深度默认受限（
cte_max_recursion_depth），长周期需调大 - 自连接性能敏感：对每个网格时间点，都要扫描原始表找
MAX(ts 和 <code>MIN(ts > grid.ts)，建议在ts字段建索引 - 线性插值公式同 PostgreSQL，但需用
TIMESTAMPDIFF(SECOND, ...)替代EXTRACT(EPOCH) - 若某点只有前值无后值（末尾），或只有后值无前值（开头），插值项为 NULL，需用
IFNULL(value, prev_val)等兜底
JOIN 后插值容易忽略的三个关键约束
很多人卡在“JOIN 出来了，但插值结果不对”，问题往往不在语法，而在隐含假设被打破：
- 时间字段类型必须一致且带时区意识：用
DATE类型 JOINTIMESTAMP会导致精度丢失，2024-01-01和2024-01-01 12:00:00视为不等 - 原始数据中同一时间戳有多条记录？未去重或未聚合（如取
AVG()）会导致 JOIN 后行数爆炸，插值基准错乱 - 插值仅适用于数值型字段：对分类字段（如设备状态码），线性插值无意义，应改用前向填充（
LAST_VALUE(value) IGNORE NULLS）或众数填充，而这不是 JOIN 能解决的
真正耗时的从来不是写 JOIN，而是确认时间粒度是否对齐、原始数据是否干净、以及插值逻辑是否匹配业务语义——比如温度适合线性，但开关状态只适合保持或跳变。
