MongoDB按date、timestamp、_id排序及find与aggregate性能差异问询

• 三者在均建立对应排序方向的匹配索引前提下，性能差异极小，完全可以忽略
• 底层存储逻辑上：MongoDB的Date类型本质就是64位整数存储，值为Unix时间戳毫秒数，和数值型timestamp字段的存储长度、比较计算逻辑完全一致，排序时的运算成本没有区别
• _id字段默认自带全局升序索引，若使用默认的ObjectId类型，其本身前缀就包含时间戳信息，按_id排序直接走原生默认索引，和另外两个字段走自定义索引的场景性能差距在统计误差范围内
• 就算是未建索引需要执行内存排序的场景，三类字段都是固定长度数值比较逻辑，排序耗时也不会出现明显差异

• 在已建全所需索引、仅投影必要字段的简单查询场景下，二者性能几乎没有差异
• 这里的简单查询特指aggregate仅使用$match+$sort+$project三个阶段，且执行计划可命中覆盖索引的情况：此时MongoDB查询优化器会将这类aggregate逻辑优化为和find完全一致的执行路径，底层执行开销没有区别
• 只有当aggregate使用了$group、$lookup等额外计算阶段时，性能才会和find拉开明显差距，符合你描述的前提的场景下不会出现显著性能差异

补充：仅3.2及更早的未维护老旧版本MongoDB存在aggregate优化器不完善的问题，同逻辑下会比find慢10%~30%，目前所有官方维护的版本都不存在该问题

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