最稳写法是ORDER BY time_column DESC LIMIT 1；需确保时间字段非空、已建索引，并按数据库类型适配语法（如SQL Server用TOP 1，Oracle 12c+用FETCH FIRST）。
直接用 ORDER BY time_column DESC LIMIT 1 是最稳的写法
绝大多数场景下，查“最近一条记录”就该这么干——先按时间字段降序排，再取第一条。不排序只加 LIMIT 1，结果完全不可靠，数据库可能返回任意一条（比如按主键顺序或存储顺序），不是“最新”，只是“碰巧第一条”。
- MySQL / PostgreSQL / SQLite：统一用
ORDER BY created_at DESC LIMIT 1 - SQL Server：换成
TOP 1，即SELECT TOP 1 * FROM t ORDER BY updated_at DESC - Oracle（12c+）：用
FETCH FIRST 1 ROWS ONLY；老版本必须嵌套ROWNUM，写法更绕 - 时间字段为
NULL时，DESC排序默认把它排在最前——你会意外拿到一条空时间的脏数据，务必加WHERE created_at IS NOT NULL
别用 MAX(time) 子查询，除非你真需要“所有同时间记录”
写成 WHERE log_time = (SELECT MAX(log_time) FROM logs) 看似语义清晰，但实际埋了两个坑：一是如果有两条记录时间完全相同，会返回两条；二是没索引时，子查询要全表扫两次，性能比 ORDER BY + LIMIT 差一截。
- 如果业务上允许“同时间只取一条”，那不如直接用
ORDER BY ... LIMIT 1，逻辑更直、性能更好 - 如果真要确保唯一性，可改用
id = (SELECT MAX(id) FROM logs WHERE log_time = (SELECT MAX(log_time) FROM logs))，但已明显变复杂，且依赖id递增特性 - 这种写法在分库分表或带分区的场景下还可能出错，因为子查询未必能下推优化
时间字段必须建索引，否则 ORDER BY DESC LIMIT 1 会越来越慢
没有索引时，数据库只能全表扫描+内存排序，哪怕只取一条，也要把几百万行都读一遍再排序。加上索引后，它可以直接跳到最大值位置，毫秒级响应。
- 单字段索引足够：例如
CREATE INDEX idx_orders_created ON orders(created_at DESC) - 如果常加条件（如查
status = 'paid'的最新订单），建联合索引更高效：CREATE INDEX idx_orders_status_time ON orders(status, created_at DESC) - PostgreSQL 支持
NULLS LAST，MySQL 不支持，所以 MySQL 想排除NULL必须显式WHERE，不能靠排序控制
窗口函数适合“分组内最新”，但单条记录纯属杀鸡用牛刀
像 ROW_NUMBER() OVER (ORDER BY created_at DESC) 这种写法，本质是给每行打序号再筛 rn = 1。对单表取最新一条，它比 ORDER BY + LIMIT 多一次全量编号，执行计划更重，IO 和 CPU 都多花一圈。
- 真正该用它的场景是：“每个用户最新一笔订单”“每类产品最新报价”——也就是
PARTITION BY user_id这类需求 - MySQL 5.7 及更早不支持窗口函数，强行用会报错；SQL Server 2005+、PostgreSQL 8.4+、MySQL 8.0+ 才可用
- 如果只是想兼容多种数据库又不愿写分支 SQL，宁可用
ORDER BY + LIMIT+ 应用层兜底，也别硬套窗口函数
时间字段是否为空、有没有索引、用的是哪种数据库——这三个点，决定了你那条“查最新”的 SQL 到底是快是慢、是准是偏。漏掉任何一个，都可能在线上突然变慢或返回错数据。
