最终耗时指订单创建至最终确定状态的时间间隔，需取最后一次状态变更时间戳；正确做法是用ROW_NUMBER()或COALESCE(paid_at, failed_at, canceled_at, updated_at)获取终态时间，再按payment_status分组聚合计算平均/最大耗时。
用 GROUP BY + 状态字段分组计算耗时
订单支付状态（如 pending、success、failed）是天然的聚合维度，但关键在于“最终耗时”的定义——它不是任意两个时间点之差，而是从订单创建到该订单**最终确定状态**的时间间隔。如果订单存在多次状态变更（比如先 pending 再 failed），必须取最后一次变更对应的时间戳。
常见错误是直接 MIN(created_at) 和 MAX(updated_at) 相减，这会把中间过程也计入，导致耗时虚高。正确做法是：对每个 order_id 先找出其最终状态及对应时间，再按状态聚合。
- 先用窗口函数
ROW_NUMBER() OVER (PARTITION BY order_id ORDER BY updated_at DESC)标记每笔订单的最新记录 - 外层只保留
rn = 1的行，确保每单只算一次“最终”状态和时间 - 再用
GROUP BY payment_status计算平均/最大/中位数耗时
处理含重试或异步回调的订单时间逻辑
真实支付场景中，updated_at 可能来自不同来源：用户前端提交、支付网关回调、人工补单等。若数据库未严格区分，仅靠 updated_at 排序可能出错——比如人工补单时间晚于实际支付成功时间，却误判为“最终状态”。
此时应优先使用带语义的字段，例如：paid_at（支付成功时间）、failed_at（失败时间）、canceled_at（取消时间）。这些字段为空即表示该状态未发生，比通用 updated_at 更可靠。
- 构建“最终状态时间”字段时，用
CASE WHEN显式判断优先级：先查paid_at，再查failed_at，最后 fallback 到updated_at - 避免直接依赖
status字段值做排序，因为状态可能被误更新（如运营手动改回pending） - 若表中无明确终态时间字段，需结合业务日志表或事件表做 JOIN，而非硬凑主表字段
MySQL 8.0+ 中一行搞定终态聚合
MySQL 8.0 支持窗口函数与 CTE，可避免多层嵌套子查询。下面这段 SQL 能直接按支付状态给出平均耗时（单位秒）：
WITH final_states AS (
SELECT
order_id,
payment_status,
created_at,
COALESCE(paid_at, failed_at, canceled_at, updated_at) AS final_time
FROM orders
WHERE created_at IS NOT NULL
)
SELECT
payment_status,
AVG(TIMESTAMPDIFF(SECOND, created_at, final_time)) AS avg_duration_sec
FROM final_states
GROUP BY payment_status;
注意 COALESCE 的顺序决定了终态时间的判定优先级；若某些状态缺少对应时间字段（如 paid_at 为空），会自动 fallback 到下一个非空值。但前提是这些字段在业务写入时已被正确填充——否则结果不可信。
PostgreSQL 中用 DISTINCT ON 处理性能敏感场景
当订单量极大（千万级以上）且无法加有效索引时，窗口函数可能变慢。PostgreSQL 提供 DISTINCT ON 作为轻量替代：它不排序全量数据，只对每个 order_id 取第一条匹配行。
- 必须配合
ORDER BY order_id, updated_at DESC才能保证取到最新状态 - 相比
ROW_NUMBER()，DISTINCT ON在有合适索引（如(order_id, updated_at DESC)）时 I/O 更少 - 但不支持跨数据库迁移——如果未来要切到 MySQL 或 ClickHouse，得重写逻辑
容易被忽略的是：DISTINCT ON 不校验状态一致性。如果某订单的 payment_status 在最新记录里是 success，但 paid_at 为空，耗时计算就会出错。所以字段完整性检查不能省。
