光源资本上周线上一个订单汇总接口突然从平均200ms涨到7秒，我第一反应是数据量涨了，可看了一眼集合，才200万条，查询条件里的两个字段也都建了索引。用explain一看，结果是COLLSCAN全表扫描。原因很拧巴：查询里用了$or，左分支走了userId索引，右分支的orderNo明明有单独索引，但优化器没法把两个索引合并成候选计划，干脆选了扫描全集。这个问题逼着我把MongoDB索引类型和索引管理重新过了一遍。
MongoDB给人的印象是"比MySQL随便"，但索引这事一样讲究。单键、复合、多键、文本、哈希、通配符、TTL、部分、稀疏，每种类型有它该出现的位置，也有它不能碰的禁区。这篇文章从底层原理开始，把每个索引类型的适用场景和限制讲清楚，再给一套从创建、监控到清理的实操方法。不管你是刚接触MongoDB的开发者，还是已经被慢查询折磨过的后台工程师，都应该能从里面找到点有用的东西。
1. MongoDB索引为什么能加速：先搞清楚底层原理
1.1 从B树说起：索引到底存了什么
MongoDB的默认索引结构是B树家族，WiredTiger存储引擎下用的是带叶子链表的B+树变种。一棵B+树的每个节点可以存多个键值，树的高度很低，100万条数据通常3到4层就能覆盖。查询时从根节点往下走，每次节点读取对应一次磁盘IO，IO次数少，查询自然快。
每个索引项存的是两部分内容：索引字段的值，以及指向原始文档的磁盘位置（RecordId）。如果你在email字段上建了索引，那么索引里存的是一串按字典序排好的邮箱地址，每个地址后面挂着一个指针，指向对应的那篇文档。复合索引则是把多个字段的值打包成一个组合键，按字段顺序逐级排序。
这个结构解释了为什么范围查询和排序在MongoDB里那么依赖索引。B+树的叶子节点之间是链式相连的，找createTime >= 2024-01-01的第一个位置，然后沿着链表往后扫就行。没有索引的话，只能从头到尾扫一遍集合并把每条文档读进来做判断。
类比一下：一本1000页的书，你要找"索引"这个词，从头翻一遍当然能找到，但如果书后面有按拼音排序的目录，你直接翻到"Y"的部分就完了。索引就是这个目录，只是它比纸质目录更精致——它按B+树组织，支持等值、范围、前缀匹配和排序，而且每次数据写入时都会自动更新。
1.2 查询优化器是怎么挑选索引的
很多人以为MongoDB会像MySQL那样用基于成本的优化器，但其实它的选择机制更"实验性"。当一个查询进来时，优化器会做这么几步：
- 找出所有可能用到的索引，为每个索引生成一个候选执行计划。
- 并行执行这些候选计划，每个计划跑一小段时间（通常就尝试几次）。
- 哪个计划最先返回第一批文档，就选它作为"获胜计划"。
- 之后相同结构的查询直接复用这个缓存计划，不再重新竞争。
这个机制有个隐含问题：第一次执行时的数据分布会影响后续很长时间的查询路径。如果数据量后来暴增，或某个字段值分布发生巨变，缓存的旧计划可能已经不适应当前数据了。典型症状就是"同一个查询，上周走索引，这周突然不走"，但代码一行没改。
遇到这种情况，除了重新分析索引，还可以清掉计划缓存。mongosh里执行db.collection.getPlanCache().clear()（不同版本的API略有差异），让优化器重新评估。这个方法在很多"诡异变慢"的场合都能救急。
回到开头那个$or例子。MongoDB对$or的处理本来就有坑：它要求每个分支都能用上索引，而且最好能走同一个索引，否则优化器会倾向于全表扫描。$or的两个分支各用一个不同索引时，新版本有些场景能合并，但很多情况下计划仍然是全表扫描。排查这类问题，我的习惯是先把$or拆成两个查询分别看执行计划，确认每个分支单独都走索引，再考虑合并。
1.3 索引不是免费的：写入放大与存储开销
建索引是有代价的，这个代价比很多人想象的大得多。每往集合里插入一条文档，所有索引都要同步更新。一个集合建了5个索引，插入一条数据，实际上要维护6份内容——1份文档数据加5份索引数据。更新字段也一样，只要被更新字段上了索引，这个索引就要调整。
所以"把可能需要查询的字段都建上索引"绝对是个危险操作。查询变快了，写入却被拖慢，索引文件还占用磁盘和内存。WiredTiger用内存缓存来加速索引访问，如果索引工作集超过可用内存，索引页就会频繁换入换出，整个实例的性能直线下降。
我见过一个实际案例：一个写多读少的日志集合，有人给十几个字段都建了索引，结果写入吞吐掉了将近一半。删掉一半冗余索引后，写入性能立刻恢复了。这个教训一直留着：索引不是越多越好，而是越精准越好。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. MongoDB索引类型逐个拆解：九种类型的适用场景与限制
2.1 单键索引与主键索引：最基础的加速器
单键索引就是在一个字段上创建的索引，也是最常见的索引类型。命令很简单：
javascript复制db.users.createIndex({ email: 1 })
这行代码给email字段建了升序索引，1表示升序，-1表示降序。单键索引适合等值查询、范围查询和排序场景。
主键索引是MongoDB默认自动创建的，建在_id字段上，唯一且不可删除。_id的类型默认是ObjectId，12字节：4字节时间戳、5字节随机值、3字节自增计数器。因为自带时间戳，按_id排序通常约等于按插入时间排序，这个特性在一些不需要精确时间的倒序场景很有用。
_id字段也可以自己指定，比如用订单号字符串或业务流水号。但要注意：如果业务里自己定义了_id，后来又想改成ObjectId，代价非常大。另外，如果_id存的是字符串，等值查询没问题，范围查询的排序规则就和ObjectId不同了，这个后面讲类型坑的时候会细说。
唯一索引是单键索引的一个重要变体：
javascript复制db.users.createIndex({ uid: 1 }, { unique: true })
唯一索引可以保证字段值的唯一性，常用于幂等控制。但创建时如果集合里已经有重复数据，命令会直接报错，需要先清理数据再建。
2.2 复合索引：命中多字段查询最常用的加速器
复合索引是在多个字段上联合建立的索引，比如：
javascript复制db.orders.createIndex({ userId: 1, status: 1, createTime: -1 })
这个索引能同时加速userId、userId+status、userId+status+createTime的查询，以及按userId+status过滤后按createTime排序的操作。为什么不能给每个字段单独建索引然后让数据库自动组合？MongoDB的优化器跟MySQL类似，单个查询通常只会选择一个索引来用。如果你分别给userId、status、createTime建了三个单键索引，一个同时过滤这三个字段的查询无法同时利用三个索引，最多只能用一个，剩下字段还要回表过滤。复合索引的本质就是提前把多个字段的过滤和排序能力合并成一个数据结构。
复合索引的字段顺序非常关键，遵循最左前缀原则。{ userId: 1, status: 1, createTime: -1 }能命中所有以userId开头的查询组合，但如果你想直接按status过滤再按createTime排序，这个索引帮不上忙。这个原则在后面的设计章节会重点展开。
复合索引里字段的方向也要注意。单个字段的方向无所谓，但如果查询里同时对两个字段排序，比如sort({ status: 1, createTime: -1 })，索引的方向必须要和排序方向完全匹配，否则MongoDB只能把数据全捞出来做内存排序。
2.3 多键索引：数组字段的特殊处理
在数组字段上建索引，MongoDB会自动为数组里的每个元素都生成一个索引项，这种索引叫多键索引。举个例子：
javascript复制db.posts.createIndex({ tags: 1 })
这样一个包含tags: ["mongodb", "database"]的文档，会在索引里生成两条记录，分别对应"mongodb"和"database"。查询{ tags: "mongodb" }时就能直接利用索引找到这篇文档。
多键索引在标签系统、分类筛选、评论ID列表这类场景非常有用。但它有两个限制要知道：
- 复合索引里最多只能有一个数组字段。比如
{ tags: 1, category: 1 }可以，但{ tags: 1, categories: 1 }会报错。 - 多键索引的explain结果里会有
isMultiKey: true标记，看到这个标记要意识到索引体积可能是普通索引的很多倍，因为每个数组元素都占一个索引项。
如果数组字段很大，或者数组元素个数不均衡，多键索引的体积膨胀会比较明显，写入开销也跟着涨。设计时尽量确认数组长度可控。
2.4 文本索引与哈希索引：两种用途完全不同的索引
文本索引用来做全文搜索。一个集合只能创建一个文本索引，但它可以覆盖多个字段：
javascript复制db.articles.createIndex({ title: "text", body: "text" })
文本索引会分析字符串内容，做分词、去停用词、词干化，然后为每个词建立倒排索引。查询用$text操作符：
javascript复制db.articles.find({ $text: { $search: "mongodb index" } })
默认是OR关系，多个词之间只要命中一个就能匹配。如果想精确短语匹配，用\"包裹。文本索引还有权重概念：createIndex({ title: "text", body: "text" }, { weights: { title: 10, body: 1 } })，标题命中比正文命中的得分高。
文本索引的坑在于：中文分词是短板。默认分词器对中文支持有限，通常需要额外处理。写入开销也大，不适合高频写入场景。
哈希索引是另一类：
javascript复制db.collection.createIndex({ shardKey: "hashed" })
对字段值做哈希运算后再建索引，目的是让分片集群里的数据分布更均匀。它天然不支持范围查询，也不支持排序，只适合等值匹配。在单机非分片环境下，如果业务只做等值查询，哈希索引也能用，但通常没必要——普通B树索引等值查询已经够快了。
2.5 通配符索引、TTL索引、部分索引与稀疏索引
通配符索引是MongoDB 4.2引入的，解决字段名不固定的文档查询问题。比如一个存储用户自定义字段的集合，不同文档的字段名完全不同，用createIndex({ "$**": 1 })就能把每个文档里所有字段都纳入索引。代价是索引体积非常庞大，只适合读多写少、字段结构高度动态的集合。
TTL索引用来自动清理过期数据：
javascript复制db.logs.createIndex({ createdAt: 1 }, { expireAfterSeconds: 86400 })
MongoDB后台有个TTLMonitor线程，大约每分钟跑一次，发现超过expireAfterSeconds的文档就删除。这个索引在日志、会话、验证码这类有时效性的数据上非常有用。限制是字段必须是Date类型，生命周期固定。注意TTL线程大批量删除过期文档时也会占用IO，比如定时任务集中在凌晨跑，TTL清理也集中在凌晨，资源就会撞车。
部分索引和稀疏索引都为了控制索引体积。部分索引通过partialFilterExpression指定哪些文档需要建索引：
javascript复制db.users.createIndex({ email: 1 }, { partialFilterExpression: { status: "active" } })
稀疏索引是部分索引的特例，只对"包含该字段"的文档建索引：
javascript复制db.users.createIndex({ phone: 1 }, { sparse: true })
两者都能减少索引条数和写入维护成本。比如大部分查询都过滤了status: "inactive"，那部分索引就特别合适。下面这个表格把几种特殊索引的核心差异列出来，方便对比。
| 索引类型 | 核心用途 | 关键限制 | 典型场景 |
|---|---|---|---|
| 通配符索引 | 字段名不固定 | 体积大，写入开销高 | 动态Schema集合 |
| TTL索引 | 过期清理 | 只支持Date字段 | 日志、会话、验证码 |
| 部分索引 | 只索引符合条件的文档 | filter表达式有限制 | 过滤低频查询的冷数据 |
| 稀疏索引 | 只索引包含该字段的文档 | 本质是字段存在性 | 可选字段的查询加速 |
3. 索引设计与优化：什么字段值得建索引，字段顺序怎么排
3.1 索引选择性：判断一个字段值不值得建索引
索引选择性 = 字段不同值的数量 / 文档总数。选择性越高，索引越有存在价值。一个email字段，每条记录几乎都不同，选择性接近1，建索引能快速定位到唯一文档。而gender字段只有两三个值，选择性极低，单独建索引几乎没什么用，因为等值查询会命中大量文档，索引回表的成本比全表扫描还高。
经验上，如果一次等值查询平均命中超过总文档数的10%~15%，优化器很可能放弃索引走全表扫描。这不是绝对规则，但可以作为设计时的参考。
那低选择性的字段是不是完全没用？不是。它可以作为复合索引的一部分。比如status只有5种状态，单独建索引没用，但在{ userId: 1, status: 1 }里，status可以帮助缩小同一个用户下的数据范围。虽然作用比userId弱，但不是完全没有。
判断一个字段值不值得建索引，我通常会看三个问题：这个字段会出现在查询条件里吗？它的选择性高吗？能用它过滤掉大部分数据吗？三个答案是"是"的字段，才值得进索引。有很多字段几乎不出现在查询条件里，或者选择性低到过滤不掉数据，建索引只是白白增加写入负担。
3.2 复合索引字段顺序：ESR原则
复合索引的字段顺序是整个索引设计里最常见的坑。业界有一个比较普适的经验法则，叫ESR原则：
- E（Equal）：等值过滤字段放在最前面。
- S（Sort）：排序字段放在第二位。
- R（Range）：范围查询字段放在最后。
为什么这么排？等值过滤字段放在最前面，能让索引在树里先按这个字段剪掉大量分支，效率最高。排序字段放在第二，是因为索引的天然有序性正好可以利用排序字段，免去内存排序步骤。范围查询字段放在最后，是因为范围条件只能确定一个区间，区间内的顺序要由后面的字段来定，所以它放在最后最合适。
举个具体例子。订单列表页常见的查询是：
javascript复制db.orders.find({
userId: "u_123",
status: "paid"
}).sort({ createTime: -1 })
按ESR原则，等值字段是userId和status，排序字段是createTime，所以索引设计为：
javascript复制db.orders.createIndex({ userId: 1, status: 1, createTime: -1 })
这个索引能同时覆盖等值过滤和排序需求，执行计划里不会出现额外的SORT阶段。如果字段顺序写反了，比如{ createTime: -1, userId: 1, status: 1 }，那等值过滤和排序都没法同时用上索引。
有个细节要注意：当范围字段和排序字段是同一个字段时，常见做法是把等值字段放前，排序/范围字段放最后。比如查询{ userId: "u_123", createTime: { $gte: ISODate("2024-01-01") } }.sort({ createTime: -1 })，索引{ userId: 1, createTime: -1 }就能满足，因为createTime同时在过滤和排序中出现，它放最后一点问题没有。
如果范围字段后面还有其他字段，比如{ userId: 1, createTime: -1, amount: 1 }，那排序createTime还能走索引，但amount的范围过滤就发挥不了太大作用了，因为索引已经按createTime排好，无法再按amount细分。遇到这种复杂需求，要么再建一个索引，要么评估一下哪个字段更重要。
3.3 覆盖查询与利用索引排序：让索引一石二鸟
覆盖查询是说查询要返回的所有字段都包含在索引里，MongoDB不需要回表读原始文档。比如索引是{ email: 1, phone: 1 }，查询：
javascript复制db.users.find({ email: "a@b.com" }, { email: 1, phone: 1 })
MongoDB可以从索引里直接拿到email和phone，不需要再去读文档数据。如果查询里出现了索引之外的字段，比如{ email: 1, phone: 1, name: 1 }，那name不在索引里，就必须回表。覆盖查询在性能上很讨喜，因为它把磁盘IO降到了最低。用explain看的时候，totalDocsExamined: 0就是覆盖查询的标志。
利用索引排序也很关键。当查询的sort字段和索引字段顺序一致时，MongoDB可以直接顺序读索引，不需要额外的SORT阶段。执行计划里一旦出现SORT，意味着数据要被拉出来排序，50万条以上的数据排序就不是闹着玩的。MongoDB的排序默认有100MB内存限制，超过会报错或写临时文件，所以高数据量的排序查询，一定要确保排序字段在索引里。
4. 索引管理实操：从创建、监控到清理的完整流程
4.1 创建索引：命令、选项与在线构建
日常里最常用的创建索引操作，在mongosh里直接执行createIndex就行。带选项的完整写法：
javascript复制db.orders.createIndex(
{ userId: 1, status: 1, createTime: -1 },
{ name: "idx_user_status_time", background: true }
)
name可以自定义索引名，方便管理；background: true在MongoDB 4.2之后的版本里意义已经变弱了，因为默认的混合索引构建方式对读写的影响比旧版小很多，但大集合构建索引依然有IO压力，最好放在业务低峰期执行。
如果你本机想验证这些操作，Debian系Linux装MongoDB，配置好官方软件源后直接apt install mongodb-org就能装上，然后启动mongod服务，用mongosh连接。生产环境部署时建议用官方源而不是发行版自带的版本，因为发行版自带包版本往往滞后。
C#开发里创建索引也很常见。用IndexKeysDefinitionBuilder：
csharp复制var keys = Builders<Order>.IndexKeys
.Ascending(x => x.UserId)
.Descending(x => x.CreateTime);
collection.Indexes.CreateOne(new CreateIndexModel<Order>(keys));
用强类型模型的好处是编译期就能发现字段拼写错误，比在mongosh里手写字符串安全得多。缺点是有些人会把一个字段定义成字符串类型，但库里实际存的是ObjectId，这里就容易埋雷，后面讲类型坑的时候细说。
创建完成后，用以下命令查看索引信息：
javascript复制db.orders.getIndexes()
db.orders.stats().totalIndexSize
getIndexes()返回索引名、字段、选项；totalIndexSize返回索引占用的字节数。定期看一眼索引大小，能帮你在索引失控之前意识到问题。
4.2 找出无用索引：索引使用统计与清理
生产环境里最容易被忽略的，是那些建了以后根本没被用过的索引。我用MongoDB的聚合阶段$indexStats来查：
javascript复制db.orders.aggregate([
{ $indexStats: {} }
])
返回结果里有每个索引的name和accesses.ops，能看到这个索引被访问了多少次。如果一个索引连续几周甚至几个月ops都是0，而且它不是唯一约束索引（唯一索引可能只是用来保证数据不重复，不是用来加速查询的）也不是TTL索引，那基本可以考虑删除。
$indexStats只统计当前节点启动后的数据。副本集环境要在primary上查才有意义，因为写操作和大部分读操作都走primary。另外，索引刚建好但业务查询还没切过去，ops也可能是0，删除前最好综合评估一下，别把刚建好的索引误删了。
删除索引用：
javascript复制db.orders.dropIndex("idx_user_status_time")
我没法再强调一遍：不要一次删多个索引。万一删错了，大集合重建索引要花很长时间，期间还会拖累线上性能。稳妥的做法是删一个，观察一段时间没有问题再删下一个。真要评估重建成本，可以在独立实例上克隆集合，把索引重建一遍，记录耗时和资源占用情况，心里有底再动手。
4.3 explain：看懂执行计划，确认索引是否真正被使用
判断一个查询到底有没有用上索引，最直接的方式是看执行计划。在mongosh里：
javascript复制db.orders.find({ userId: "u_123", status: "paid" }).sort({ createTime: -1 }).explain("executionStats")
重点看几项：
queryPlanner.winningPlan.stage：如果是IXSCAN，说明走了索引；如果是COLLSCAN，就是全表扫描。executionStats.totalKeysExamined：扫描了多少索引项。executionStats.totalDocsExamined：回表读了多少文档。executionStats.executionTimeMillis：实际执行时间。
一个理想的执行计划是：totalKeysExamined等于实际命中的文档数，totalDocsExamined很小，最好为0（覆盖查询）。
比如执行计划里出现这样的片段：
json复制"winningPlan": {
"stage": "FETCH",
"inputStage": {
"stage": "IXSCAN",
"keyPattern": { "userId": 1, "status": 1, "createTime": -1 }
}
}
这说明走了索引。如果winningPlan.stage是COLLSCAN，那就要怀疑是不是索引没有落到这个查询上，或者最左前缀没匹配。
hint可以强制指定走某个索引，常用于验证索引是否有效，比如：
javascript复制db.orders.find({ userId: "u_123", status: "paid" }).hint({ userId: 1, status: 1, createTime: -1 }).explain("executionStats")
但生产环境不要长期依赖hint。数据分布变化后，优化器可能比你更清楚该走哪条路，强制索引可能会导致本来挺快的查询反而变慢。
5. 索引失效排查：那些"建了索引却不走"的坑
5.1 最左前缀原则被破坏：复合索引失效的主因
复合索引{ userId: 1, status: 1, createTime: -1 }，查status和createTime却不用userId，这个索引基本没用。这就是最左前缀原则——复合索引只能从第一字段开始连续匹配，跳过了前面的字段，后面的字段就发挥不了作用。
常见的不走索引操作有这些：
- 查询条件里用了
$where，这个无论如何都不会走索引。 - 用了
$expr，MongoDB需要在文档层面做表达式计算，索引没法参与。 - 正则表达式不是
^开头，比如{ name: /张三/ }无法利用索引；但{ name: /^张三/ }可以。 $not、$ne这类操作符，即使走了索引也往往要扫描大量索引项，性能很差。- 对字段做运算的函数式写法，比如
{ $expr: { $gt: ["$price", 100] } }，索引失效。
另外还有两个容易误判的操作符：$or和$in。$in在单个字段内通常可以顺利走索引，因为它本质上可以拆成多个等值条件的并集。$or就比较麻烦，如果每个分支都能用索引还好说，一旦有一个分支没法走索引，整个查询很可能就变成全表扫描了。
| 操作符 | 索引友好度 | 说明 |
|---|---|---|
$eq/$in |
高 | 等值，索引首选 |
$gt/$lt/$gte/$lte |
中 | 范围，复合索引会放最后 |
$ne/$not |
中低 | 排除类，索引扫描范围很大 |
正则^前缀 |
中 | 可以走索引 |
| 非前缀正则 | 低 | 基本全表扫 |
$expr/$where |
极低 | 无法利用索引 |
排查时先看查询条件是不是符合最左前缀，再看用了什么操作符，这两步能解决大部分"建了索引却不走"的问题。
5.2 类型不匹配与隐式转换：long、字符串、ObjectId
MongoDB是BSON类型敏感的数据库，同一个字段里如果混存了不同类型，索引的效果会大打折扣。搜索热词里有"long类型相加"，我猜说的是这个场景：操作符本身没问题，但类型没对上导致走不了索引。
比如温度采集表里有个temperature字段，大部分文档都存的是数字类型，某一天写入程序出了bug，存了一条字符串"36.5"。之后执行范围查询：
javascript复制db.sensors.find({ temperature: { $gte: 36.5 } })
那条字符串类型的"36.5"不会被返回，因为它和数字36.5在BSON里是不同类型，MongoDB比较时会按类型层级走，数字和字符串不可直接比较。这还不算，如果混存的字符串很多，索引的选择性也会下降，优化器可能干脆不选这个索引了。
在C#这类强类型语言里更容易踩这个坑。实体类里定义了一个long属性，但MongoDB驱动写入时可能因为类型映射不一致，库里存成了Int32或Int64。查询时如果传入的是另一个类型，虽然MongoDB对int、long、double之间会做数值比较，但一旦有字符串类型混进来，范围查询就可能失效。另外，如果你把一个本应是ObjectId的字段定义成string，那按ObjectId范围排序的查询结果就完全不对，因为字符串排序和ObjectId排序规则不同。
解决办法其实不复杂：写入前用mongo shell或者脚本检查一下字段类型分布，看看有没有杂类型数据；在应用层做好类型校验，防止脏数据混进去。已经产生了脏数据的历史集合，要么清洗，要么把这个字段的值统一转类型。MongoDB没有MySQL那种"前缀索引"，但你可以加一个冗余字段来模拟这个效果，比如存一个"归一化后的排序字段"，让业务查询走这个字段的索引。
5.3 审计、锁与索引争用：容易被忽略的运维侧问题
搜索热词里提到"数据库开启审计引起索引争用"，这个现象我之前遇到过。开启审计后，数据库会记录大量操作日志，如果审计日志写入压力大，或者审计模块执行了低效查询，WiredTiger的并发管理会变得紧张。表现是：每个查询单独看执行计划都正常，走索引也走了，但整体延迟很高，CPU很高，查询排队严重。
排查时不要只盯着执行计划，还要看并发事务情况。currentOp能查当前正在跑的操作和锁等待；db.serverStatus().wiredTiger.concurrentTransactions能看到读写事务的ticket使用率。如果ticket被占满，说明系统在并发层面已经饱和了，索引争用只是表象，真正的问题是资源竞争。
类似的情况还有索引构建和业务查询争用。虽然MongoDB 4.2以后默认使用混合索引构建，但大集合构建索引依然会带来IO压力，严重时会拖慢同一节点的所有查询。所以生产环境里做索引变更，最好选在业务低峰期，而且要用currentOp监控构建进度，别让它和业务高峰撞在一起。
排查索引争用的路径大概是：先看所有节点是否延迟增大，再看磁盘IO和CPU，再看WiredTiger的并发ticket，最后看有没有索引在后台构建。一层层查下来，基本上能定位到是哪个环节出了问题。