正确做法是用 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 可能报错，这类细节上线前必须验证。
