从建索引到查询加速：实战指南的第一步：理解数据与查询模式
在 MongoDB 中进行索引优化的核心是理解业务查询模式，只有明确哪些字段会出现在查询条件、排序条件以及聚合阶段，才能设计出高效的索引结构。作为 PHP 开发者，你需要把数据库设计与应用代码的访问模式紧密结合，而不是凭直觉凑出几个常用字段就一锤定音。
慢查询日志与执行计划是关键证据。通过分析慢查询的出现频率、谓词覆盖度、以及执行计划中的阶段性耗时，可以发现是否有全表扫描、索引未被使用或前缀不匹配的问题。持续关注这些数据，有助于在后续步骤中快速定位索引改造点。
明确业务查询的字段
在实际项目中，最常用的查询往往围绕用户、时间、状态等维度展开。将最频繁使用的查询字段列成清单，并评估它们是否能通过一个或多个索引来快速定位数据。
对于高并发写入场景，二选一原则很关键：要么以写入吞吐为优先，减少写入时的索引负担，要么以查询性能为优先，接受一定的写入成本换取快速读取。
收集慢查询日志与执行计划
开启慢查询日志并收集执行计划，可以看到查询如何被优化器处理，是否伴随索引覆盖、字段排序以及投影的使用情况。
结合应用日志，把同一业务线的典型查询聚合成模式，便于后续统一设计复合索引；同时记录查询的输入参数分布，帮助判断是否需要对低基数字段建立索引。
在 MongoDB 中正确创建索引的实操要点
创建索引不仅要“多跑一个索引”，还要考虑字段顺序、类型与唯一性。错误的字段顺序可能导致索引无效，错过前缀匹配，甚至让查询仍走全表扫描。
复合索引的前缀原则是核心：在多数实际查询中，最常用的查询条件子集应在复合索引的前缀位置，以确保能有效地利用该索引定位数据。
单字段索引与复合索引的权衡
单字段索引简单直观，适合低基数字段或极其明确的查询条件；但当应用场景中存在多条件的并发查询时，复合索引能显著提升命中率，降低查询成本。
在 PHP 端实践时，优先级要清晰：先为最常用的查询条件建立单字段索引，再在核心的组合查询上引入复合索引，避免过度索引带来的写入负担与空间浪费。
复合索引前缀要符合最常用查询前缀
设计复合索引时，以最常见的查询前缀为首要前缀，其次才是二级条件。若大多数查询以 order_id 为主键条件，其次是 status，则应将 order_id 放在前缀位置。
此外，索引覆盖查询（covered query）要尽量实现，使查询能仅通过索引返回需要的字段，避免回表读取实际文档，提高响应速度。
确保稀疏索引、唯一性与背景建索引
对可为空的字段，考虑使用稀疏索引以节省存储与提高写入吞吐。若某字段具备唯一性约束，应该使用唯一索引来保障数据完整性且提升查询效率。
背景创建索引对线上应用友好，不会阻塞写操作；在需要更低停机时间时，可以采用后台索引策略并监控对现有查询的影响。
查询加速的策略：如何让查询走索引
对查询进行 explain 分析，是判断是否走索引的直接手段。通过 explain 的输出，可以看到谓词匹配、扫描阶段、排序与投影的成本分布，进而调整索引。
尽量避免不等号、正则匹配与未用前缀的查询，这类查询容易导致全表扫描或低效的索引利用。若不可避免，应通过重构查询或增加合适的前缀索引来改善。
使用 explain 评估查询计划
在 PHP 项目中，可以通过先构建查询再获取 explain，快速判断执行计划是否使用了期望的索引。
结合分析，对慢查询进行分组和对比，看是否存在“按字段排序导致无法使用前缀索引”的情况。
shop->orders;
// 示例查询：使用复合索引 order_id + status
$cursor = $collection->find(['order_id' => ['$gte' => 1000], 'status' => 'PAID'])
->sort(['order_id' => 1]);
$explain = $cursor->explain();
print_r($explain);
?>避免全表扫描和排序导致的索引失效
若查询需要排序，尽量让排序字段成为索引前缀的一部分，以便查询可以利用索引返回排序后的结果，避免额外的 sort 阶段开销。
当排序字段与查询条件未对齐时，考虑创建覆盖排序的复合索引，或对数据模型进行轻量级调整，以使常用排序具备可被索引的前缀结构。
实战技巧：基于场景驱动的索引设计
以实际业务场景驱动索引设计，才能获得稳定的查询加速。下面给出典型电商与日活场景的设计要点，帮助你把抽象改成可执行的工程实践。
在电商订单场景中，优先考虑以 order_id、user_id、status、create_time 等字段组合的复合索引，以覆盖常用的查询与过滤组合。
电商订单场景下的索引设计
典型查询包括查询用户最近的未支付或已完成的订单、按时间段筛选的订单列表等。复合索引应覆盖常见的时间区间与状态条件，提升分页和排序的速度。
示例设计原则：前缀优先覆盖时间范围与用户标识，二级条件再落在状态、商户等字段，确保最常用的查询能走索引。
shop->orders;
// 电商场景：复合索引（user_id, create_time, status）
$collection->createIndex(['user_id' => 1, 'create_time' => -1, 'status' => 1], ['name' => 'user_time_status_idx']);
?> 日志与分析场景的索引设计
对于日志来源的分析场景，字段如 host、service、log_level、timestamp、message_id 常被用来筛选与聚合。将时间戳作为前缀的一部分，是提升时间序列查询效率的关键。
聚合管道中的分组字段也应考虑索引覆盖，减少阶段间的数据往返与内存消耗。
logs->events;
// 日志场景的复合索引（timestamp, service, log_level）
$collection->createIndex(['timestamp' => 1, 'service' => 1, 'log_level' => 1], ['name' => 'ts_service_level_idx']);
?> 监控与维护：索引的增长与优化的持续性
索引并非一次性解决方案，需定期评估和维护。随着数据量增长、查询模式变化，原有索引的效果可能下降，因此需要持续关注。
定期检查索引状态、碎片与覆盖情况，并通过 explain 与统计信息评估新的优化点，避免过量的冗余索引占用资源。
索引碎片化与定期重建
随着写入删除的混合操作，某些索引段可能产生结构碎片，降低查询性能。适时进行重建或重建策略调整可恢复高效访问。
在 PHP 应用中，可以结合维护任务周期性运行，对热数据区域的索引进行重点监控与维护，确保长期性能稳定。
监控工具与告警机制
利用 MongoDB 自带的监控工具或云端管理平台，设置慢查询阈值、索引缺失告警与容量预警，提早发现潜在的性能瓶颈。
将监控结果与版本控制结合，在代码提交或部署时同步更新索引策略，确保上线后具备追踪的可观测性。
