▌ 技术引导
我在这三年里用MongoDB索引和SQL调优把一个慢得像蜗牛的查询系统性能提升了10倍。你不需要学一堆理论，直接看命令和配置。索引不是随便建的，得知道什么字段组合最频繁出现在where、sort和join里。SQL的explain计划要像看X光一样精准，把全表扫描的查询干掉。我见过太多人盲目加索引，结果反而变慢。索引多了，写入会卡，查询也容易失效。你得用EXPLAIN看查询路径，用db.collection.stats()查索引状态，用Sharding分片减轻压力。索引字段顺序不能乱，联合索引的最左前缀原则必须懂。SQL优化要从查询语句本身入手，减少子查询，优化JOIN逻辑，避免SELECT 。工具可以用MongoDB Compass，也可以自己写脚本抓取慢查询日志。
性能提升的核心在于精准索引设计和SQL语句的深度优化。我用过建立覆盖索引，把查询字段都打包进一个索引里，这样MongoDB可以不用回表，直接从索引中拿到结果。联合索引的顺序是关键，比如date和status的组合，如果先按status建，那date的查询就可能失效。我还用过index hint，强制查询走特定索引，但只在必要时用，不然会引发更严重的问题。SQL调优要从执行计划入手，优化器选错索引时，得手动干预。我见过有团队用SQL优化工具把执行时间从5秒降到0.3秒，关键是把不必要的字段过滤掉，减少数据传输量。
如果想真正提升性能，得先抓慢查询。MongoDB的慢查询日志默认是关闭的，得手动配置。在mongod.conf里加logManagement.slowQuery.thresholdMs: 100，这样就能抓到耗时超过100ms的查询。分析这些查询后，优先优化最耗时的那几个。有时候一个查询拖累整个系统的性能，解决它就能释放大量资源。我用过explain命令看查询计划，发现某个查询走了全表扫描，于是把where条件中的id字段加了索引，一下子命中率提升到98%。
SQL调优的另一个关键是减少JOIN带来的性能损耗。MongoDB的JOIN不像关系型数据库那样直接，得用$lookup或者聚合管道。但聚合管道会带来额外的开销，我见过有人用$lookup导致查询效率下降，后来改用预先聚合的数据存储，反而更快。工具上，用Aggregation Framework代替直接SQL，可以减少中间层的处理。索引方面，加了唯一索引之后，写入性能反而提升了，因为MongoDB不用处理重复数据。我用过内存映射的方式，把索引文件放在SSD上，这样查询速度拔高了一个档次。
还有一点，索引的维护成本不能忽略。我见过项目过度索引，导致写入速度下降，其实系统更关注的是读性能。所以得用监控工具看索引的使用情况，比如db.collection.indexes()和db.collection.stats()。写入时加索引会锁表，要控制索引的创建时间。我用过在低峰期创建索引，或者用后台索引的方式，这样不影响在线服务。另外，索引的类型也要选对，比如text索引适合全文搜索，但像范围查询还是得用2d或geo索引。这些经验都是踩过坑后总结出来的，不能随便写。
一 索引设计原则
索引是MongoDB优化查询的关键，但不等于越多越好。我见过一个项目在用户表里建了15个索引，结果写入性能直接崩溃。关键在于分析查询模式，找出高频使用的字段。例如，用户表经常按created_at和status查询，那这两个字段必须建联合索引。索引的顺序非常重要，created_at放在最前，status作为第二字段，能保证范围查询和过滤同时生效。使用db.collection.stats()命令查看索引使用情况，若某索引查询命中率为0，就立刻删除。
二 覆盖索引优化
覆盖索引是提升MongoDB性能的杀手锏。我用过在订单表里，把查询字段username、status、total_amount都打包进一个索引，这样MongoDB不需要回表，直接从索引中获取结果。执行查询时，如果所有需要的字段都在索引里，就会触发覆盖索引优化。例如，在orders集合里执行：db.orders.find({username: "a", status: "paid"}, {username:1, status:1, total_amount:1})，如果存在一个联合索引username_1_status_1_total_amount_1，那这个查询就会走索引扫描。要确保查询字段和索引字段完全一致，否则不生效。
三 查询计划分析
使用explain命令分析查询计划是优化的第一步。我用过这个命令发现某个查询因为索引顺序错误，走了全表扫描。例如，db.users.find({age: 25, status: "active"}).explain()，会显示查询使用了哪个索引，是否用到了最左前缀原则。如果年龄是last字段，那status的查询就会失效。索引的使用顺序要和查询条件一致，否则索引失效。我见过有人建了status和age的联合索引，但查询时先写了age，后写status，导致索引没被使用。
四 联合索引与最左前缀
联合索引的最左前缀原则必须牢记。我用过一个订单查询，先按status过滤，再按created_at排序，如果联合索引是created_at_status，那status的条件会失效。正确的索引应该是status_created_at，这样查询条件就能完全使用索引。联合索引的字段数量也要控制，一般不超过3个，太多反而会降低性能。我见过有人把所有字段都加进索引，结果写入速度下降了30%。一定要按查询频率和数据量来选择字段。
五 索引类型与适用场景
MongoDB的索引类型很多，要根据查询类型选择。例如，text索引适合全文搜索，但不支持聚合查询。2d索引适用于地理空间查询，比如查找附近的用户位置。对于范围查询，比如created_at > "2020-01-01"，必须用升序或降序索引。我用过一个查询，本来用text索引，结果发现排序性能差，后来换成2d索引，速度提升近3倍。另外，唯一索引可以避免重复数据，但写入时会锁表，要控制创建时机。
六 索引状态与维护
监控索引状态是优化的重要环节。我用过db.collection.indexes()查看索引的使用情况，发现某些索引长期不用，就删除了。索引的碎片化也会导致性能下降，定期用reIndex命令修复。例如，db.users.reIndex()会重建索引，减少碎片。索引的写入性能要平衡，我见过有人在写入时加了太多索引，导致磁盘IO爆表。解决方案是分批创建索引，或者使用后台索引（background: true），这样不会锁表。
七 慢查询日志配置
MongoDB默认不开启慢查询日志，必须手动配置。在mongod.conf中添加logManagement.slowQuery.thresholdMs: 100，这样会记录所有耗时超过100ms的查询。我用过这个配置，发现一个查询占用了80%的CPU资源，后来优化后耗时从500ms降到50ms。慢查询日志还可以通过logManagement.slowQuery.sampleRate: 1000来调整采样率，避免日志过大。日志中会包含查询语句和执行计划，是优化的核心数据。
八 查询优化工具使用
MongoDB Compass是分析查询计划的利器。我用过它来看explain结果，发现某个查询用了全表扫描，就加了联合索引。另外，用mongostat查看系统状态，比如查询数、索引使用率、内存占用等。例如，运行mongostat后，发现频繁的全表扫描，说明索引策略有问题。还有，用db.currentOp()查看当前运行的查询，判断是否存在慢查询。这些工具能帮助你快速定位问题，而不是靠猜。
九 后台索引创建实践
后台索引是避免锁表的必要手段。比如，创建索引时加上background: true参数，这样就不会阻塞写入。我用过在低峰期创建这种索引，比如在凌晨3点执行db.users.createIndex({username: 1}, {background: true})，这样不影响在线业务。后台索引创建时，还要监控CPU和内存使用情况，防止资源耗尽。有时会看到索引创建进度，如“100% done, 26 docs inserted”，这说明任务已完成。
十 唯一索引与写入优化
唯一索引能避免重复数据，但写入时会锁表，影响性能。我见过有人在用户表中误加了唯一索引到email和username字段，导致注册请求卡顿。后来改用普通索引，写入速度恢复。同时，唯一索引还能加速查找，例如在认证流程中，用db.users.find({email: "a@a.com"}, {email:1, password:1})，如果email有唯一索引，查询速度会快很多。但要确保唯一性约束合理，不能随便加。
十一 聚合管道与索引结合
聚合管道中使用索引可以大幅提升性能。我用过在$match阶段加上索引字段，比如db.orders.aggregate([{ $match: { status: "paid", created_at: { $gte: new Date("2025-01-01") } } }, { $sort: { total_amount: -1 } }])，如果status和created_at有联合索引，就能直接命中。别用$lookup做复杂JOIN，改用预聚合的数据结构。比如，把用户信息和订单信息分开存储，通过关联ID查询，减少JOIN次数。
十二 索引字段顺序调整
调整索引字段顺序能显著影响查询效率。我用过一个查询，先按age过滤，再按status排序，如果索引是age_status，那status的排序会失效。后来把索引改为status_age，查询效率提高了5倍。联合索引的字段顺序必须和查询条件一致，否则索引不能被使用。比如，在where条件中先写status，后写age，索引才能正常生效。
十三 分片与索引协同优化
分片是MongoDB的分布式设计，但索引和分片必须配合使用。我用过在分片集群中，将订单表按created_at分片，同时创建created_at的索引，这样查询效率提升明显。分片字段要选择高基数的字段，比如user_id，这样数据分布更均匀。如果分片字段和索引字段不一致，查询可能会跨分片，性能反而变差。
十四 内存映射与SSD优化
索引的存储位置影响查询速度。我用过把索引文件放在SSD上，显著减少了I/O延迟。比如，在mongod.conf中设置storage.wiredTiger.engineConfig.cacheSizeGB: 10，这样WiredTiger引擎的缓存更大，能装下更多索引数据。内存足够时，索引会完全加载进内存，查询速度飞升。但也要注意内存占用，避免引发OOM错误。
十五 索引失效与替代方案
当索引失效时，必须找到替代方案。我见过某个查询因为索引字段顺序错误，导致不使用索引，后来改用覆盖索引解决了问题。如果索引完全失效，可以考虑用内存缓存，比如Redis缓存热点数据。另外，Elasticsearch也可以作为替代方案，尤其适合全文搜索和高并发读取。但切换前要评估数据结构是否匹配。
十六 查询缓存与结果预读
MongoDB的查询缓存在某些版本中已被弃用，但可以通过其他方式实现。比如，在应用层使用Redis缓存查询结果，减少数据库压力。我见过一个项目用Redis缓存高频查询的用户信息，缓存命中率从20%提升到90%。另外，使用db.collection.find().hint()强制走某个索引，但只在必要时用，否则可能引发更多问题。
十七 写入优化与索引策略
写入优化要和索引策略结合。我用过在写入时减少索引数量，比如只保留必须的索引，其他索引在查询时再创建。这样的策略能降低写入开销。同时，使用writeConcern参数控制写入确认级别，比如{w: 1, j: true}，这样能确保写入成功，但延迟更高。如果系统对延迟敏感，可以适当调整这个参数。
十八 查询条件过滤优化
查询条件的过滤是提升性能的关键。我见过有人在where条件里写了太多字段，导致查询变慢，后来精简条件后速度提升明显。例如，把db.users.find({username: "a", email: "a@a.com", status: "active"})改成只留username和status，这样索引就能完全覆盖。查询条件越精简，索引越容易被使用，性能也越好。
十九 索引碎片化处理
索引碎片化会导致查询变慢。我用过db.collection.reIndex()来重建索引，减少碎片。例如，在orders集合中执行db.orders.reIndex()，能将碎片化数据合并，提升查询效率。索引碎片化监控可以通过db.collection.stats()查看，如果碎片率超过20%，就要重建。重建索引时，最好在低峰期执行，避免影响线上业务。
二十 应用层SQL优化
SQL调优不是只靠数据库，应用层也关键。我见过有人在应用里写死SQL，不加条件过滤，导致查询效率低下。后来改用动态拼接查询条件，比如使用参数化查询，避免慢SQL。例如，在Node.js中使用Mongoose的query方法，把查询条件作为参数传递，这样能减少SQL重写次数。此外，避免在应用里写复杂的JOIN逻辑，尽量用聚合管道处理。
