直接取每组按业务字段降序排列后row_number()为2的记录；需确保排序字段准确反映业务顺序，显式处理null，并用主键保证稳定性。
用 ROW_NUMBER() 倒序分组取倒数第二条的通用写法
直接结论：对每组按时间/ID 降序排列，取 ROW_NUMBER() OVER (PARTITION BY group_col ORDER BY sort_col DESC) 等于 2 的记录即可。关键不是“倒数”，而是“按业务逻辑降序后排第 2”。
常见错误是先升序再想“倒数第二”，结果绕进子查询嵌套或 MAX() + NOT IN 里，既难读又慢。
-
ORDER BY必须明确指定业务上“最新”或“最后发生”的字段（如created_at、id），不能依赖无序表的物理顺序 - 如果存在并列（比如同一秒插入多条），
ROW_NUMBER()仍会强制编号，而RANK()或DENSE_RANK()可能跳过 2 —— 这时就不是“倒数第二条”，而是“排名为 2 的记录” - MySQL 8.0+、PostgreSQL、SQL Server、Oracle 都支持，但 SQLite 3.25+ 才支持窗口函数
处理 NULL 或重复排序值导致的错位问题
当 sort_col 有 NULL，默认排序会把它们排在最前（ASC）或最后（DESC），导致 ROW_NUMBER() 编号偏移。例如按 updated_at DESC，若某组有两条记录 updated_at 都是 NULL，它们可能被编为 1 和 2 —— 但这显然不是你要的“倒数第二条”。
- 显式控制
NULL位置：ORDER BY updated_at DESC NULLS LAST（PostgreSQL/Oracle 支持）；MySQL 和 SQL Server 需用ORDER BY IFNULL(updated_at, '1970-01-01')类似技巧 - 避免仅靠单字段排序产生歧义：在
ORDER BY后追加主键（如ORDER BY created_at DESC, id DESC），确保排序稳定、可复现 - 如果业务上“倒数第二”要求严格去重（如相同时间只算一条），得先
DISTINCT ON（PostgreSQL）或用GROUP BY预聚合，再套窗口函数
性能敏感场景下的替代方案（不依赖窗口函数）
在旧版 MySQL（ROW_NUMBER() 不可用，硬套子查询容易全表扫描。这时更务实的做法是用自连接或 LIMIT/OFFSET（仅限单组）。
- 单组快速取倒数第二：
(SELECT * FROM t WHERE group_col = 'X' ORDER BY sort_col DESC LIMIT 1 OFFSET 1)—— 注意OFFSET 1跳过最新那条，取下一条 - 多组且需兼容老版本：用相关子查询统计“比当前记录更新的记录数”，例如
(SELECT COUNT(*) FROM t t2 WHERE t2.group_col = t1.group_col AND t2.sort_col > t1.sort_col) = 1，但数据量大时性能差 - 索引必须覆盖
(group_col, sort_col)，否则PARTITION BY + ORDER BY会失去优化基础
为什么不能直接用 LAST_VALUE 或 LAG
LAST_VALUE() 默认是 ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW，不加 ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING 就永远拿不到组内最后一条；而 LAG(col, 1) 是“向前看一行”，不是“倒数第二”。两者语义和用途都不同。
-
LAST_VALUE(sort_col) OVER (PARTITION BY group_col ORDER BY sort_col ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING)只返回每行对应组的最后值，不是整行记录 -
LAG()在组内第一行返回NULL，无法定位“倒数第二”这个固定位置 - 真正要的是位置偏移（position-based），不是值偏移（value-based）——所以
ROW_NUMBER()是唯一简洁可靠的解法
最容易被忽略的是排序字段的业务含义是否真能定义“倒数”。比如用 id DESC 假设 ID 严格递增且代表时间顺序，但遇到批量导入、UUID 主键或分布式 ID 就失效了。别省那一步验证。
