无索引、分区及Sharding时，如何快速检索MySQL百万行表time_stamp？建索引是否不可取？

1. 无索引、分区、分片时能否高效检索time_stamp？ #

很难做到真正意义上的高效——没有索引的情况下，MySQL只能执行全表扫描，百万级数据的扫表操作必然带来较高IO和耗时。但可以通过一些手段降低扫描成本：

• 利用id与time_stamp的关联关系：如果数据写入时按time_stamp递增顺序插入，time_stamp和主键id会呈现正相关。这时可先估算目标时间范围对应的id区间，用WHERE id BETWEEN ? AND ?过滤，再在小范围内筛选time_stamp，大幅减少扫描行数。
• 利用覆盖查询优势：由于表仅包含id和time_stamp两列，全表扫描时MySQL可直接读取数据文件的连续块，无需回表，相比多列表的扫表速度会快一些，但本质还是全表遍历。
• 冷数据归档：定期将过期历史数据迁移到离线存储（如CSV文件、归档表），只保留近期热点数据在主表。这样全表扫描的行数大幅减少，查询速度会有明显提升，但只是缩小了扫描范围，并未改变扫表的本质。

2. 给time_stamp建索引是糟糕的做法吗？ #

完全不是，这才是应对这类查询的最优常规方案：

• 对于基于time_stamp的过滤查询，B+树索引能将查询时间复杂度从全表扫的O(n)降到O(log n)，百万级数据下性能提升极其显著，可直接将秒级查询压缩到毫秒级。
• 唯一潜在代价是写入时的索引维护开销，但对于仅含主键和time_stamp的表，这个开销非常小——索引结构简单，写入时的额外IO和CPU消耗完全在MySQL承受范围内，不会对写入性能造成明显影响。
• 面试官禁止建索引大概率是为了考察你对MySQL底层机制的理解和变通思路，但在实际生产环境中，给查询过滤字段建索引是最合理、最高效的选择，绝不是糟糕的做法。

内容的提问来源于stack exchange，提问作者Bhuvaneshkumar J