sql子查询无法预测eta，仅能基于静态结构化数据做确定性计算；它适合拼接多表时效字段生成基准值，如嵌入路线标称时长，但不能建模历史延误、外部因素或动态波动，预测逻辑应交由应用层完成。
单纯靠 SQL 子查询无法预测 ETA（预计到达时间）——它没有时间序列建模、历史延误分析或外部因素（如天气、交通）接入能力，只能基于已有结构化数据做确定性推算。
子查询能做什么：从物流表里提取“可计算的中间状态”
真正能用子查询完成的，是把分散在多张表里的时效相关字段拼成一个可比对的基准值。比如：orders 表记录下单时间，shipments 表记录发货时间，routes 表存各线路的标称运输时长（单位：小时）。
- 子查询适合做“单次快照式计算”，例如：
(SELECT avg_duration FROM routes WHERE route_id = s.route_id)作为运输基准值嵌入主查询 - 不能替代模型——它不会因为上周该线路 30% 的包裹晚点 2 小时，就自动给本次计算加缓冲时间
- 若
routes表里只有固定值（如“上海→北京：48h”），子查询返回的就是这个静态值；一旦实际运输时间波动，结果立刻失真
常见错误：把子查询当预测引擎，结果被业务方打回
典型翻车场景是写类似这样的语句：
SELECT order_id,
(SELECT MIN(arrival_time) FROM delivery_history WHERE route_id = o.route_id) AS predicted_eta
FROM orders o;
问题在于：
-
MIN(arrival_time)返回的是历史最快一次，不是典型值，更不是概率分布下的 P90 时间 - 没过滤掉异常样本（如某次因疫情封控导致 168 小时送达，拉低了整个 MIN）
- 子查询未关联
order_date，导致拿全年数据去预测今日订单，忽略季节性（如双十一流量峰值） - 如果
delivery_history没有索引在route_id + order_date上，这种子查询会全表扫描，查 10 万订单直接拖垮数据库
务实做法：子查询只负责“组装输入”，预测逻辑交给应用层
让 SQL 做它最擅长的事：把干净、对齐、带上下文的数据准备好，然后交给 Python/Java 做真实预测。
- 用子查询聚合出每个订单的特征向量：
(SELECT AVG(duration_h) FROM delivery_history dh WHERE dh.route_id = s.route_id AND dh.order_date >= CURRENT_DATE - INTERVAL '7 days')→ 近 7 天平均时效 - 用
LEFT JOIN替代相关子查询，避免 N+1 查询：主表orders一次性关联routes和近 7 天delivery_stats视图 - 务必在子查询里加
LIMIT 1或明确ORDER BY ... DESC LIMIT 1，否则 MySQL 可能报错 “Subquery returns more than 1 row” - 如果下游要用这些字段训练模型，别在 SQL 里做
ROUND()或CAST()，保留原始精度，类型转换留给 Pandas 处理
真正影响 ETA 准确率的，是能否拿到实时中转站滞留数据、车辆 GPS 轨迹、甚至快递员接单后 3 分钟内是否扫码出仓——这些根本不在传统 SQL 能触达的范围。子查询只是把数据库里已有的、离线的、确定性的信息链串起来，别指望它自己学会看天气预报。
