ORDER BY date_column DESC 按日期降序排序，但需确保字段为 DATE/DATETIME 类型；若为字符串需转换，多列排序须显式声明 DESC，时区字段应统一存 UTC 并显式转换，大表须建索引避免 filesort。
ORDER BY date_column DESC 会按日期降序排，但要注意字段类型是否真是 DATE/DATETIME
如果 date_column 是字符串（如 '2023-01-15' 类型的 VARCHAR），即使格式统一，排序也可能出错——比如 '2023-10-01' 会排在 '2023-02-01' 前面，因为字符串比较从左到右逐字符进行。实际执行前先确认类型：
SELECT DATA_TYPE FROM INFORMATION_SCHEMA.COLUMNS WHERE TABLE_NAME = 'your_table' AND COLUMN_NAME = 'date_column';
若结果是 varchar 或 text，得先转成日期再排序，例如：ORDER BY STR_TO_DATE(date_column, '%Y-%m-%d') DESC（MySQL）或 ORDER BY TO_DATE(date_column, 'YYYY-MM-DD') DESC（PostgreSQL）。
DESC 关键字必须紧跟在列名或表达式之后，不能单独写在 ORDER BY 后面
常见错误写法：ORDER BY date_column DESC NULLS LAST（PostgreSQL 支持，但 MySQL 不认）；或更典型的：ORDER BY date_column DESC, id——这里 id 默认是升序，不是降序。要让多列都降序，得显式写全：ORDER BY date_column DESC, id DESC。另外，DESC 对大小写不敏感，但别写成 desc 或 Desc 混用，虽多数引擎容忍，但可读性差、易被误判为别名。
带时区的 DATETIME 排序可能因时区转换导致意外顺序
PostgreSQL 中 TIMESTAMP WITH TIME ZONE 字段在排序时会自动转为当前会话时区再比较；MySQL 的 TIMESTAMP 也隐式做 UTC 转换。如果业务要求严格按原始录入时间（比如日志系统），建议：
- 存储统一用 UTC（推荐）
- 查询时避免依赖会话时区，显式用 AT TIME ZONE（PostgreSQL）或 CONVERT_TZ()（MySQL）对齐后再排
- 若字段是 DATETIME（无时区），则不会自动转换，但要注意它不记录时区信息，跨系统同步时容易歧义
大表加 ORDER BY date DESC 可能慢，没索引就别硬扛
当数据量超 10 万行，又没在日期字段建索引，ORDER BY date_column DESC 很可能触发 filesort，拖慢查询。验证方式：执行 EXPLAIN SELECT * FROM your_table ORDER BY date_column DESC LIMIT 10;，看 Extra 列是否含 Using filesort。解决办法只有两个：
- 建倒序索引（MySQL 8.0+ 支持 CREATE INDEX idx_date_desc ON your_table (date_column DESC);）
- 旧版 MySQL 或其他引擎，建普通 B-tree 索引即可（B-tree 天然支持正/逆序扫描，只要 ORDER BY date_column DESC 是最左前缀且无其他混合方向排序）
日期排序看着简单，真正上线后卡顿、顺序错乱、跨时区异常，八成出在字段类型、索引缺失或时区假设上。别急着加 DESC，先 DESCRIBE 表结构，再看执行计划。
