直接在fs.files.length建索引无效是因为字段名误写（如size）或文档缺失length字段；正确做法是确认字段存在后创建{length: 1}或{length: -1}单字段索引，并在排序查询中用.sort({length: 1})配合.allowDiskUse(true)。
为什么直接在 fs.files.length 上建索引没效果？
因为 GridFS 的 fs.files 集合默认不包含 length 字段——它实际叫 length，但类型是 64 位整数（long），而早期 MongoDB 驱动或 shell 中若用错字段名（比如误写成 size 或 fileSize），索引会建在空值上，查询时根本用不上。
更关键的是：GridFS 规范要求文件元信息必须存进 fs.files，其中文件大小字段名就是 length，且该字段始终存在、非空。只要确认文档里有这个字段，建索引就有效。
- 用
db.fs.files.findOne({})检查是否存在length字段（不是size） - 如果返回文档含
"length" : 12345，说明字段名和值都正确 - 若字段缺失，说明文件不是通过标准 GridFS API 写入的（比如手动插入或用了旧版驱动）
如何正确创建升序/降序 size 索引
索引本身很简单，但顺序影响排序性能：升序索引（1）对 .sort({length: 1}) 最优；降序索引（-1）对 .sort({length: -1}) 最优。MongoDB 不会复用反向索引做排序，所以按需建一种即可。
- 升序索引（适合查“最小的 10 个文件”）：
db.fs.files.createIndex({length: 1}) - 降序索引（适合查“最大的 10 个文件”）：
db.fs.files.createIndex({length: -1}) - 不要建复合索引如
{length: 1, uploadDate: -1}来支持分页，除非你总按这两个字段联合排序——否则纯增加写开销
排序查询时必须避免的三个错误
即使索引建对了，查询写法不对，MongoDB 依然无法使用索引做排序，会回退到内存排序（in-memory sort），超 100MB 就报错 Sort exceeded memory limit。
- 漏掉
.sort()：只用.find().limit(10)是无序的，结果不可预测 - 用错字段名：
.sort({size: -1})或.sort({"metadata.size": -1})—— 这两个字段都不存在，索引完全不触发 - 没加
.allowDiskUse(true)：当结果集大、排序内存不够时，必须显式启用磁盘临时文件，否则直接失败
正确写法示例（Node.js driver）：
collection.find({}).sort({length: -1}).limit(10).allowDiskUse(true)
真实场景下的性能差异有多大？
在 50 万文件的 fs.files 集合上实测：没索引时，.sort({length: -1}).limit(10) 平均耗时 3.2 秒，且每次都要扫描全表；加了 {length: -1} 索引后降到 18ms，响应稳定。
但注意：索引不能加速「范围查询 + 排序」混合操作。例如 find({uploadDate: {$gt: ISODate("2023-01-01")}}).sort({length: -1})，除非同时建复合索引 {uploadDate: 1, length: -1}，否则仍可能慢。
真正容易被忽略的是：GridFS 文件删除后，fs.files 文档不会自动清理（除非调用 delete() 方法），所以索引体积会持续增长，定期 db.fs.files.getIndexes() 检查索引大小很有必要。
