lead函数仅按排序取下一行数据，非预测模型；需结合时间差与库存变化率手动计算耗尽时间，并处理负增长、除零、边界及数据库兼容性问题。
LEAD 函数本身不预判，它只取下一行数据
LEAD 不是预测模型，也不会自动推算“耗尽时间”。它只是按指定排序，把后续某行的 quantity 或 record_time 拉到当前行——真正的预判逻辑得靠你用这些值手动计算。常见误用是直接写 LEAD(quantity) 就以为能得出预警时间，结果发现只是抄了个数字，没算速率、没考虑负增长、也没处理边界。
真正可用的思路是：先用 LEAD 拿到相邻两条记录的库存和时间，再算出单位时间消耗量，最后用当前库存除以该速率，推得剩余时间。
- 必须显式指定
ORDER BY，通常按record_time ASC；不写会报错或结果不可靠 - 推荐用
LEAD(quantity, 1) OVER (ORDER BY record_time)而非默认偏移（即省略第二个参数），避免隐式依赖 - 若记录间隔不均（比如一天一次、有时隔三天），直接用行数差算速率会失真，得先算时间差（
LEAD(record_time)）再转换为小时/分钟
计算剩余时间时，必须处理除零和负速率
库存表里可能有补货记录（quantity 上升），导致 LEAD(quantity) - quantity 为正——这时速率是负的，“耗尽时间”无意义。更危险的是，当两次记录库存相等，分母为零，SQL 会返回 NULL 或报错（取决于数据库），而你可能没意识到这个 NULL 已悄悄让整列预警失效。
- 用
CASE WHEN LEAD(quantity) 过滤非消耗场景 - 时间差必须转成数值单位：PostgreSQL 用
EXTRACT(EPOCH FROM (LEAD(record_time) - record_time))/3600得小时；MySQL 用TIMESTAMPDIFF(HOUR, record_time, LEAD(record_time)) - 最终剩余小时 =
quantity / ((quantity - LEAD(quantity)) / time_diff_hours)，分子分母都得加NULLIF(..., 0)防除零
真实库存场景中，LEAD 只能看“最近一段”，不是长期预测
LEAD 最多拉一行（或指定 N 行），意味着你只能基于最新两条记录估算速率。一旦中间有补货、促销突增、传感器断连，这个速率就严重偏离实际。它适合做“短时盯盘”（比如未来 4 小时预警），不适合替代 forecast 模型。
- 不要用
LEAD(quantity, 5)拉五条后算平均——中间可能混入异常值，且无法对齐时间轴 - 若需平滑，应在应用层聚合（如每小时取 min(quantity)），再对聚合后序列用 LEAD；数据库内做窗口平均 + LEAD 容易嵌套过深、难以调试
- 生产环境务必加
WHERE record_time > NOW() - INTERVAL '7 days'限定范围，避免扫描全表拖慢查询
不同数据库对 LEAD 的 NULL 处理差异很大
同一段 SQL 在 PostgreSQL、MySQL 8.0、SQL Server 上跑，LEAD(quantity, 1, 0) 的第三个参数（默认值）行为一致，但遇到排序字段重复时表现不同：MySQL 可能任意打乱同时间戳的行序，导致 LEAD 拉到错误行；SQL Server 默认稳定排序，PostgreSQL 则要求显式加 record_time, id 多重排序才可靠。
- 永远在
OVER子句里写完整排序：ORDER BY record_time, id，哪怕id是自增主键 - 避免用
LEAD(quantity, 1)不带默认值——最后一行必为NULL，如果下游用COALESCE(LEAD(...), 0)掩盖，可能把“无后续数据”误读为“库存归零” - ClickHouse 不支持 LEAD，得改用
neighbor()；Doris 需开启窗口函数开关，否则静默报错
LEAD 是把好刀，但库存耗尽这事，本质是用旧数据猜未来——它只负责递给你下一颗子弹的时间戳，扣不扣扳机、朝哪打，还得你定规则、控边界、验数据源。别让它替你做决定。
