LEFT JOIN中ON条件使用ABS(TIMESTAMPDIFF())会导致性能极差，因其使右表无法使用索引，强制全表扫描匹配；且该函数需对每行组合实时计算，时间复杂度陡增。
为什么 LEFT JOIN 加 ABS(TIMESTAMPDIFF) 会慢得离谱？
直接在 ON 条件里写 ABS(TIMESTAMPDIFF(SECOND, a.ts, b.ts)) 看似合理，实际会导致全表笛卡尔积扫描。MySQL 无法利用索引加速这种非等值、带函数的关联条件，哪怕两边 <code>ts 字段都有 B+ 树索引，优化器也会放弃使用。
实操建议：
- 先用
WHERE限定时间窗口（比如b.ts BETWEEN DATE_SUB(a.ts, INTERVAL 5 MINUTE) AND DATE_ADD(a.ts, INTERVAL 5 MINUTE)），让索引生效，缩小候选集 - 再在缩小后的结果里用
ROW_NUMBER() OVER (PARTITION BY a.id ORDER BY ABS(TIMESTAMPDIFF(SECOND, a.ts, b.ts)))排序取最近一条 - 避免在
ON中对字段做任何函数运算，包括CAST()、DATE()、TIMESTAMPDIFF()
MySQL 8.0+ 怎么用 ROW_NUMBER() 实现“每行找最接近的那条”？
核心思路是：不追求一次性 Join 出结果，而是先生成所有可能配对（受限于时间窗），再按主表 ID 分组排序，取序号为 1 的记录。
示例（a 表为主，找 b 表中时间戳最接近的单条记录）：
SELECT a.id, a.ts AS a_ts, b.id AS b_id, b.ts AS b_ts
FROM a
LEFT JOIN (
SELECT *,
ROW_NUMBER() OVER (
PARTITION BY a_id ORDER BY ABS(TIMESTAMPDIFF(SECOND, a_ts, ts))
) AS rn
FROM (
SELECT a.id AS a_id, a.ts AS a_ts, b.id, b.ts
FROM a
INNER JOIN b ON b.ts BETWEEN DATE_SUB(a.ts, INTERVAL 5 MINUTE) AND DATE_ADD(a.ts, INTERVAL 5 MINUTE)
) t
) ranked ON ranked.a_id = a.id AND ranked.rn = 1;注意：PARTITION BY a_id 必须和主表关联字段一致；ORDER BY ABS(...) 是排序依据，但必须配合外层 LEFT JOIN + rn = 1 才能保证“每 a 行最多一条 b”。
PostgreSQL 怎么用 LATERAL 避免全量配对？
LATERAL 允许子查询引用左侧表字段，天然适合“对每一行执行一次带索引限制的查找”，性能远优于 MySQL 的窗口函数方案。
实操建议：
- 确保
b.ts有 B-tree 索引：CREATE INDEX idx_b_ts ON b(ts); - 用
ORDER BY b.ts <-> a.ts（PostgreSQL 的距离操作符）替代ABS()计算，更高效 - 加
LIMIT 1强制只取最近一条，避免多余排序
示例：
SELECT a.id, a.ts, b.id AS b_id, b.ts AS b_ts
FROM a
LEFT JOIN LATERAL (
SELECT id, ts
FROM b
WHERE b.ts >= a.ts - INTERVAL '5 minutes'
AND b.ts <= a.ts + INTERVAL '5 minutes'
ORDER BY b.ts <-> a.ts
LIMIT 1
) b ON TRUE;时间戳精度不一致（秒 vs 毫秒）会导致匹配失败吗？
会。比如 a 表用 DATETIME（秒级），b 表用 BIGINT 存毫秒时间戳，直接比大小或算差值会因量级错位完全失准。
关键检查点：
- 确认两边时间基准是否一致（Unix epoch 起点？时区？）
- 统一转换后再比较：
FROM_UNIXTIME(b.ts / 1000)或UNIX_TIMESTAMP(a.ts) * 1000 - MySQL 中
TIMESTAMPDIFF对单位敏感，SECOND和MICROSECOND结果差 10⁶ 倍，务必核对参数 - PostgreSQL 中
to_timestamp()默认接收秒，毫秒需除以 1000
最容易被忽略的是时区隐式转换——TIMESTAMP 类型受 session timezone 影响，而 DATETIME 不受，混用时可能偏移数小时。
