正确做法是用 MIN(listed_at) OVER() 计算全量最早上榜时间,再与当前日期求差,并前置过滤 NULL 和未来日期;FIRST_VALUE 需显式指定整窗范围且 ORDER BY 必须升序。

用 FIRST_VALUE 配合日期差算“上榜最久”容易错在窗口定义
直接套 FIRST_VALUE 求最早时间,再和当前行日期相减,结果往往不对——因为默认窗口是 ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW,不是整表范围。若没显式写 ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING,每行的“最早上榜时间”只取到当前行为止,不是全量最小值。
正确做法是强制窗口覆盖全部数据:
SELECT id, name, listed_at, DATEDIFF(CURDATE(), FIRST_VALUE(listed_at) OVER (ORDER BY listed_at ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING)) AS days_on_list FROM rankings;
注意:FIRST_VALUE 的 ORDER BY 必须是 listed_at 升序,才能拿到最早时间;降序会得到最新时间,完全跑偏。
DATEDIFF 在不同数据库里参数顺序不一致
MySQL 的 DATEDIFF(end_date, start_date) 返回正数;但 PostgreSQL 用 end_date - start_date(支持直接减),SQL Server 用 DATEDIFF(day, start_date, end_date)。跨库迁移时,如果只改函数名不调换参数,天数会变负。
常见适配建议:
- MySQL / MariaDB:保持
DATEDIFF(CURDATE(), listed_at) - PostgreSQL:改用
(CURRENT_DATE - listed_at),类型自动推导为整数天数 - SQL Server:必须写成
DATEDIFF(day, listed_at, GETDATE()),且第一个参数是单位字符串
查“上榜时间最长的记录”不等于查 FIRST_VALUE 行
FIRST_VALUE 只能帮你算出每个记录“已上榜多少天”,但要找出最大值对应的那条记录,得再套一层过滤或排序。直接 WHERE days_on_list = (SELECT MAX(...)) 会有多个并列第一的风险,且性能差。
更稳妥的方式是用窗口函数排倒序取首行:
SELECT id, name, listed_at, days_on_list
FROM (
SELECT
id,
name,
listed_at,
DATEDIFF(CURDATE(), MIN(listed_at) OVER()) AS days_on_list,
ROW_NUMBER() OVER (ORDER BY listed_at ASC) AS rn_first
FROM rankings
) t
WHERE rn_first = 1;
这里用 MIN(listed_at) OVER() 更简洁安全——它天然作用于整窗,无需担心 ROWS 范围;ROW_NUMBER() 按 listed_at 升序排,第一条就是最早上榜的记录。
真实场景中 listed_at 为空或未来日期必须先清洗
上线后常发现结果异常,一查是部分 listed_at 为 NULL 或误填了 2099-01-01 这类占位值。这些会导致 MIN() 或 FIRST_VALUE() 计算失真,甚至让 DATEDIFF 返回 NULL。
务必前置过滤:
- 加
WHERE listed_at IS NOT NULL AND listed_at - 若业务允许“未正式上线”,可用
COALESCE(listed_at, '1970-01-01'),但需同步注释说明逻辑 - 避免在
OVER()子句里用WHERE——窗口函数执行前不走 WHERE,必须在外层或 CTE 中筛
真正麻烦的是历史数据里混着时间精度不一致的字段:有的存 DATETIME 带时分秒,有的只存日期。比大小时 MySQL 会隐式对齐,但 PostgreSQL 可能报错,这类细节上线前必须验证。










