JOIN时需对齐时间戳精度，避免因秒级与毫秒级不一致导致漏匹配；应统一截断至相同精度（如DATE_TRUNC('second', event_time)），并注意时区一致性。
JOIN时必须对齐时间戳的精度单位
订单状态流转断点常出现在「看似有记录，实则跨毫秒/秒错位」的情况。比如orders表用created_at（精确到秒），而status_logs表用event_time（精确到毫秒），直接ON o.id = s.order_id AND o.created_at = s.event_time会漏掉所有记录。
实操建议：
- 先用
SELECT EXTRACT(EPOCH FROM created_at)或DATE_TRUNC('second', event_time)统一截断到秒级再JOIN - 若需毫秒级对齐，确认两边字段是否同为
TIMESTAMP WITH TIME ZONE，避免隐式时区转换导致偏移 - 用
ABS(EXTRACT(EPOCH FROM s.event_time) - EXTRACT(EPOCH FROM o.created_at)) 代替等值匹配，容忍5秒内扰动
LEFT JOIN + IS NULL才是找断点的核心写法
想定位「创建了但没触发首状态」或「上一状态后无下一状态」这类断点，不能只用INNER JOIN——它只返回有匹配的行，而断点恰恰是缺失的那一侧。
典型场景：查所有已创建但尚未进入'paid'状态的订单
SELECT o.order_id, o.created_at FROM orders o LEFT JOIN status_logs s ON o.order_id = s.order_id AND s.status = 'paid' WHERE s.order_id IS NULL;
关键点：
-
WHERE s.order_id IS NULL必须写在JOIN之后，不能写成AND s.order_id IS NULL放在ON里（那会变成过滤条件，破坏LEFT语义） - 若要查「有paid但无shipped」，需两次LEFT JOIN，第二次ON中排除已存在的shipped记录
- 注意NULL和空字符串区别：
s.status IS NULL≠s.status = ''，状态字段最好设为NOT NULL
用窗口函数配合JOIN识别状态跳跃断点
业务中常见「从created直接跳到delivered，中间missing paid/shipped」，这种非连续流转靠普通JOIN很难捕获，需先按订单+时间排序生成序列，再与自身JOIN比对前后状态。
实操步骤：
- 用
ROW_NUMBER() OVER (PARTITION BY order_id ORDER BY event_time)给每单状态打序号 - 把结果集自JOIN：
ON a.order_id = b.order_id AND a.rn + 1 = b.rn，得到相邻状态对 - 加
WHERE (a.status, b.status) NOT IN (('created','paid'), ('paid','shipped'), ('shipped','delivered'))筛出非法跳转 - 注意：若同一时间有多条日志（如并发更新），需用
RANK()或加id主键去重，否则序号可能重复
索引不覆盖JOIN条件会导致超慢甚至超时
当orders有千万级、status_logs过亿时，没索引的LEFT JOIN ... ON order_id可能跑十几分钟，根本没法排查断点。
必须检查并补全：
-
status_logs(order_id, event_time)复合索引（顺序不能反，order_id必须在前） - 若常按状态筛选，改为
(order_id, status, event_time)，让WHERE status = 'paid'也能走索引 - 对
orders(created_at)单独建索引意义不大，JOIN主要依赖order_id字段的等值匹配效率 - 用
EXPLAIN ANALYZE确认执行计划里是否出现Hash Join或Merge Join，避免Nested Loop扫全表
状态流转断点往往藏在时间精度错位、LEFT语义误用、相邻状态缺失校验这三个地方，光看数据表结构看不出问题，得动手跑一次带IS NULL的LEFT JOIN才能暴露真实缺口。
