MySQL 时间列上 ORDER BY 不走索引的可能原因

sql -- 索引：idx_event_time (event_time) SELECT * FROM events ORDER BY DATE(event_time); -- 不走索引 SELECT * FROM events ORDER BY UNIX_TIMESTAMP(event_time); -- 不走索引

**原因**：对索引列使用函数（或表达式），MySQL 无法直接使用索引中存储的原始值进行排序，必须先计算出结果再排序。  
**解决**：尽量对原始列直接排序。如果必须按日期部分排序，可考虑创建函数索引（MySQL 8.0.13+ 支持）或生成列索引。

```sql
-- 方案1：直接使用原始列排序（通常可走索引）
SELECT * FROM events ORDER BY event_time;

-- 方案2：创建函数索引（MySQL 8.0.13+）
ALTER TABLE events ADD INDEX idx_date ((DATE(event_time)));
SELECT * FROM events ORDER BY DATE(event_time);

2.2 索引定义与 ORDER BY 列顺序不匹配

索引 (user_id, event_time) 对 ORDER BY event_time 无法用于排序，除非 event_time 前面列的条件是常量。

-- 索引：idx_user_time (user_id, event_time)
SELECT * FROM events WHERE user_id = 100 ORDER BY event_time;  -- 走索引排序
SELECT * FROM events ORDER BY event_time;  -- 无法使用该索引排序，会回退到 filesort

ORDER BY 单独使用 event_time 时，由于索引必须以 user_id 为前缀，无法直接从 event_time 开始扫描，因此索引无法满足排序需求。

解决：根据查询模式创建覆盖排序需求的索引。如果常见查询只是按时间排序，可以单独为 event_time 创建索引。

2.3 WHERE 条件中包含范围查询，导致后续排序列索引失效

-- 索引：idx_time (event_time)
SELECT * FROM events WHERE event_time > '2024-01-01' ORDER BY event_time;

这个查询通常能正常使用索引。但如果索引是 (key1, event_time)，且 WHERE 条件对 key1 使用了范围查询，则 event_time 部分无法用于排序：

-- 索引：idx_key1_time (key1, event_time)
SELECT * FROM events WHERE key1 > 100 ORDER BY event_time; -- event_time 排序不走索引

原因：范围条件后的索引列不再用于排序，因为无法保证在 key1 的不同区间内数据按 event_time 全局有序。

解决：调整索引顺序，将等值查询列放在前面，范围查询列尽量靠后。如果必须如此，可以考虑为 ORDER BY 列单独建立索引。

2.4 排序字段与 WHERE 条件列不在同一个索引中

-- 索引：idx_status (status)
SELECT * FROM events WHERE status = 1 ORDER BY event_time;

status 上的索引无法提供 event_time 排序。优化器只能选择使用 idx_status 过滤数据，然后对结果集进行 filesort。

解决：创建 (status, event_time) 的联合索引，这样过滤和排序都可以通过一个索引完成。

2.5 混合 ASC/DESC 排序

SELECT * FROM events ORDER BY event_time ASC, id DESC;

早期 MySQL 版本（5.7 及之前）对混合排序方向很不友好，即使符合条件的索引存在，也可能不采用。MySQL 8.0 支持降序索引后，可以显式定义索引的排序方向来匹配查询。

解决：升级到 MySQL 8.0，创建对应方向的索引。

-- MySQL 8.0 降序索引
ALTER TABLE events ADD INDEX idx_time_iddesc (event_time ASC, id DESC);

2.6 查询涉及 LIMIT 但优化器误判代价

有时索引可用于排序，但 MySQL 优化器评估后认为全表扫描 + filesort 比使用索引更“便宜”。这种情况常发生在表数据量很小或 WHERE 条件过滤性很差的时候。

-- 即使 (event_time) 存在索引，也可能不走
SELECT * FROM events ORDER BY event_time LIMIT 10;

验证方法：使用 EXPLAIN FORMAT=JSON 查看各执行路径的 cost，或用 FORCE INDEX 强制使用索引比较查询耗时。

解决：如果确认索引排序更优，可使用 FORCE INDEX 提示，或调整 optimizer_switch 相关参数。

2.7 使用了 SELECT *，没有覆盖索引

即使索引能用于排序，但如果需要回表读取大量数据，优化器可能认为全表扫描更直接。特别是当 ORDER BY 结果集很大时，大量随机 I/O 回表会导致性能下降。

-- 索引：idx_time (event_time)
-- 不走索引排序（即使可能有效），优化器可能选择 filesort + 顺序读
SELECT * FROM events ORDER BY event_time;

解决：让查询成为覆盖索引，减少回表代价。

-- 只需索引列
SELECT event_time FROM events ORDER BY event_time;

-- 或创建覆盖索引
ALTER TABLE events ADD INDEX idx_time_cover (event_time, col1, col2);

2.8 时间列类型与索引列类型不一致造成隐式转换

时间列定义为 VARCHAR 或 INT 但存储时间戳，与 ORDER BY 中使用的字符串比较时可能发生隐式转换，导致索引失效。更常见的是时间列为 DATETIME，但查询中混入了字符串或数字比较。

-- event_time 是 DATETIME 类型
SELECT * FROM events ORDER BY event_time;  -- 一般没问题
-- 但如果索引建立在 VARCHAR 时间列上，ORDER BY 使用了 UNix 时间戳转换，则不走索引