必须在ORDER BY中包含唯一列才能保证分页稳定，因为排序字段重复时数据库不保证相同值记录的相对顺序，导致ROW_NUMBER()分配序号不确定，引发数据跳变；正确写法是ORDER BY created_at DESC, id DESC，确保每行排序位置唯一。
必须在 ORDER BY 中包含唯一列，否则分页结果每次查询都可能错乱。
为什么排序字段重复会导致分页不稳定
窗口函数如 ROW_NUMBER() 依赖排序的确定性。如果只按 created_at 排序，而多条记录时间相同，数据库没有义务保持它们之间的相对顺序——两次查询可能分配不同序号，导致同一页数据忽有忽无、某条记录反复出现或彻底消失。
- 典型现象：
OFFSET 40 LIMIT 20和ROW_NUMBER() OVER (ORDER BY created_at DESC)都会出问题，不是LIMIT专属 - 执行计划里看不到异常，但应用层翻页时数据“跳变”，尤其在高并发写入场景下更明显
-
EXPLAIN无法直接暴露该问题，需靠业务数据验证：连续查两次第 5 页，比对id列是否完全一致
ORDER BY 必须怎么写才真正稳定
核心是让每行在排序序列中有唯一位置，不能依赖数据库的“默认行为”。
- 写法必须是类似
ORDER BY created_at DESC, id DESC—— 第二字段必须是表中能打破并列的唯一列（通常是主键id） - 方向要明确：
id DESC和id ASC效果不同，需与业务逻辑匹配（比如“最新创建+同时间取最大ID”） - 不能用表达式包裹，例如
ORDER BY DATE(created_at), id会让索引失效，且DATE()本身不保证稳定性 - 如果业务排序逻辑复杂（如按部门销售额总和降序），
PARTITION BY+ORDER BY也得确保分区内部有唯一决胜字段
别名 rn 为什么不能直接用在 WHERE
ROW_NUMBER() 是窗口函数，生成的别名 rn 属于“投影阶段”，在 SQL 执行顺序中晚于 WHERE。所以 WHERE rn BETWEEN 1 AND 10 会报错 Invalid column name 'rn'。
- 正确做法只有两种：套子查询（
SELECT * FROM (SELECT ..., ROW_NUMBER() ...) t WHERE t.rn ...）或用WITHCTE - 别名
rn不可省略，否则外层无法引用；也不能起名row_num后又写WHERE rownumber—— 名字必须严格一致 - 不要试图绕过：写成
HAVING rn BETWEEN 1 AND 10无效，HAVING只作用于GROUP BY结果
索引没生效？先看这三件事
加了 INDEX (created_at DESC, id DESC) 还慢，大概率不是语法问题，而是索引没被用上。
-
WHERE条件字段没进联合索引：比如查询带WHERE status = 'active'，但索引只建在(created_at, id)，数据库可能弃用该索引 - 类型不匹配：表字段是
TIMESTAMP，索引却建在DATETIME上，隐式转换导致索引失效 -
EXPLAIN里key显示NULL或不是你预期的索引名，rows接近全表总数 → 索引根本没参与排序
真正容易被忽略的是：稳定性不是“写对语法就完事”，它依赖排序字段、索引定义、查询条件三者严丝合缝。少一个环节，ROW_NUMBER() 就只是看起来漂亮而已。
