MongoDB按startTimestamp排序是否需索引？索引优缺点及效果疑问

是否需要为startTimestamp创建索引？ #

必须建。你的查询是先全集合扫描所有文档，再对结果排序。数据量小的时候还能凑合用，数据量上来后，MongoDB得把所有文档加载到内存里排序，一旦数据超过默认约32MB的sortBufferSize，就会写到磁盘临时文件里排序，速度直接垮掉。给startTimestamp建索引后，查询能直接顺着索引的有序性返回结果，完全不用额外排序，性能会跳级提升。

索引的缺点 #

• 拖慢写入速度：每次插入、更新或删除带startTimestamp的文档时，MongoDB不光要改文档本身，还得同步更新对应的索引结构，会额外耗CPU和IO，写入性能肯定会降一点。
• 占额外磁盘空间：索引本身要占磁盘存储，单字段索引的大小大概是字段数据大小加索引元数据，数据量越大，索引占的空间越多。
• 可能干扰查询计划：如果后续有其他复杂查询，MongoDB的查询优化器说不定会选错索引，导致某些查询变慢，得定期检查查询计划。

怎么确认索引有没有提升查询速度？ #

1. 看查询执行计划：跑db.mycollection.find( {} ).sort( {startTimestamp: -1} ).explain("executionStats")命令，重点盯这几个点：
   • executionStats.executionStages.stage：显示IXSCAN就是用到索引了；要是COLLSCAN，那还是全表扫描，索引没生效。
   • executionStats.totalDocsExamined：用索引的话这个数会远小于集合总文档数（全表扫描时等于总文档数）。
   • executionStats.executionTimeMillis：对比建索引前后的执行时间，明显变少就说明有用。
2. 实际测响应时间：在相同数据量下，分别记一下建索引前后查询的响应时间，直观对比快慢。
3. 看数据库资源消耗：监控MongoDB的CPU、IO使用率，建索引后查询时的资源消耗应该会降低（尤其是IO，不用全表扫了）。

内容的提问来源于stack exchange，提问作者Björn Konrad