带递增id条件与LIMIT的MySQL查询是否默认按id返回结果？

优化中的查询语句 #

我正在优化查询以提升性能，使用的SQL语句如下：

SELECT * FROM my_table
WHERE status_flag = 0
  AND event_date = '2025-03-25 23:59:59.999'
  AND id > 42006893
LIMIT 5000;

每次迭代时我会增大id条件的值来缩小结果集。

EXPLAIN输出结果 #

非峰值日期场景 #

当event_date为非峰值日期时，EXPLAIN结果为：

1  SIMPLE  my_table  (null)  index_merge  PRIMARY,idx_event_date  idx_event_date,PRIMARY  14,8  (null)  98045  10  Using intersect(idx_event_date,PRIMARY); Using where

峰值日期场景 #

当event_date为峰值日期（如28日）时，EXPLAIN结果为：

1  SIMPLE  my_table  (null)  range  PRIMARY,idx_event_date  PRIMARY  8  (null)  52926100  1  Using where

核心问题 #

结合以下条件，想确认两种场景下MySQL是否都会默认按id返回结果：

• event_date字段建有索引idx_event_date
• 使用id > X条件逐步缩小结果集
• 查询未显式指定ORDER BY id

确保覆盖所有相关记录对我至关重要，而这只有在结果按id排序时才能保障。我将上述查询与带ORDER BY id的语句做了对比：

SELECT * FROM my_table
WHERE status_flag = 0
  AND event_date = '2025-03-25 23:59:59.999'
  AND id > 42006893
ORDER BY id
LIMIT 5000;

二者结果大致相同。我推测因为idx_event_date索引附带隐藏主键，所以即使不指定ORDER BY id，结果也会按id排序。

解答 #

针对你给出的两种执行计划场景，当前情况下结果确实都会按id排序，具体分析如下：

1. 非峰值日期（index_merge + intersect） #

这里MySQL使用了intersect(idx_event_date, PRIMARY)的索引合并策略：

• idx_event_date作为二级索引，叶子节点会附带主键id，且本身是按event_date + id排序的；
• PRIMARY是主键索引，按id有序存储；
• 当用intersect合并两个索引的结果时，MySQL会以主键索引的顺序来返回数据，最终结果自然按id升序排列。

2. 峰值日期（range扫描PRIMARY索引） #

此时MySQL直接选择扫描主键索引的范围（id > 42006893），而主键索引本身就是按id从小到大有序存储的，所以扫描出来的结果会直接按id顺序返回。

注意事项 #

虽然当前测试结果和显式加ORDER BY id的一致，但从MySQL的官方规范来说：如果查询未显式指定ORDER BY，MySQL不保证结果排序的稳定性。也就是说，未来如果数据分布变化、统计信息更新、MySQL版本升级等因素导致执行计划改变，隐含的排序逻辑可能会失效。

如果你的业务场景对"按id排序、不遗漏记录"有强要求，最稳妥的方式还是显式加上ORDER BY id，避免依赖执行计划的隐含行为带来的风险。

内容的提问来源于stack exchange，提问作者Ruibin Zhang