MySQL 8.0+强制要求ROW_NUMBER()的OVER子句必须包含ORDER BY，否则直接报错；缺ORDER BY会导致语义缺失、结果不可复现，且性能严重下降，必须配合索引和正确过滤时机。
MySQL 8.0+ 直接报错：Window 'w' requires an ORDER BY clause
不是警告，是硬性语法错误。只要写 ROW_NUMBER() OVER () 或任何窗口函数带空 OVER()，MySQL 就拒绝执行，提示明确错误信息：Window 'w' requires an ORDER BY clause。它不接受“默认顺序”“物理存储顺序”这类模糊概念——SQL 标准要求窗口内行序必须可复现，而物理顺序不可靠（如 INSERT 乱序、VACUUM 后重排、并行扫描路径变化等）。
常见误操作包括：
- 复制 PostgreSQL 或 SQL Server 旧脚本，直接粘贴到 MySQL 环境中运行
- 在视图定义里写
ROW_NUMBER() OVER ()，结果保存失败或被静默截断 - 用 ORM 自动生成 SQL 时未适配 MySQL 8.0+ 的严格模式
ORDER BY 不是“为了排序好看”，而是定义窗口逻辑边界
窗口函数依赖行序做计算，比如 LAG() 取上一行、SUM() OVER (ROWS BETWEEN 1 PRECEDING AND CURRENT ROW) 算滑动和——没有 ORDER BY，数据库根本不知道哪一行是“上一行”。哪怕你只想要编号，ROW_NUMBER() 也必须知道“从哪开始数、按什么顺序数”。
省略 ORDER BY 的后果不是“没排序”，而是语义缺失：
-
LAST_VALUE(x) OVER (PARTITION BY a)：返回每个分区里“哪一行”的 x？不确定 -
AVG(x) OVER (ORDER BY y ROWS BETWEEN 2 PRECEDING AND 2 FOLLOWING)：不指定ORDER BY y，数据库无法定位“前后两行”是谁 - 即使你加了
PARTITION BY，没ORDER BY时默认窗口是UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING（整个分区），但行序仍是随机的
为什么不能用 ORDER BY (SELECT NULL) 或类似伪方案？
MySQL 不支持 ORDER BY (SELECT NULL) 这种写法，会报语法错误。PostgreSQL 虽允许 OVER ()，但结果顺序由扫描路径决定，VACUUM 或 ANALYZE 后可能变；SQL Server 和 Oracle 同样强制要求显式 ORDER BY 字段。
想“快速生成稳定行号”，唯一合规做法是选一个有索引支撑、值稳定、非空的字段，例如：
- 主键
id（推荐，通常已有聚簇索引） - 带索引的时间字段
created_at（注意 NULL 值默认排最前，需加NULLS LAST显式控制） - 组合字段如
(user_id, created_at)，对应复合索引(user_id, created_at DESC)
别试图绕过 ORDER BY，它不是性能负担的源头，而是语义正确性的门槛。
最容易被忽略的一点：ORDER BY 字段没索引，性能会断崖下跌
写了 ORDER BY 只是语法过关，不代表执行快。如果排序字段没索引，或者索引不匹配 PARTITION BY + ORDER BY 顺序，数据库就得对每个分区做全量文件排序（Using filesort），内存撑爆就落盘，查询从毫秒变秒级甚至分钟级。
验证方式很简单：
- 跑
EXPLAIN ANALYZE，看是否有Sort节点，Extra 是否含Using filesort - 检查索引是否为复合索引，且第一列为
PARTITION BY字段，第二列为ORDER BY字段，方向一致（如ORDER BY created_at DESC需要索引里也写DESC） - WHERE 条件必须放在窗口计算之前，否则过滤下推失败，白排几百万行
真正卡住的从来不是语法，而是以为“加上 ORDER BY 就万事大吉”，却没给它配好索引和过滤时机。
