AWS企业账号购买 AWS DocumentDB (MongoDB 兼容) 查询缓慢与索引失效排查
很多人遇到 DocumentDB 慢查询，第一反应是“索引坏了”，但我实际处理过的案例里，真正的问题往往不是单点索引，而是查询写法、字段类型、排序方式、网络路径、账号权限、账单状态一起叠加出来的。
如果你现在已经在 AWS 上开了 DocumentDB，先别急着重建索引。先按下面的顺序查，通常能少走很多弯路。
一、先判断：到底是数据库慢，还是账号/网络把你拖慢了
| 现象 | 更常见的原因 | 优先处理 |
|---|---|---|
| 同一条查询时快时慢 | 跨区访问、连接池不足、应用层重试 | 先看应用部署区域和连接数 |
| 返回 20 条，扫描几十万条 | 索引没命中或排序字段不匹配 | 看 explain 的扫描量 |
| 新账号建库慢、实例创建失败 | 支付验证失败、账号风控、额度未放开 | 先处理账单和验证 |
| 白天正常，批处理时突然变慢 | 并发上来后 CPU/IO 吃满 | 看 CloudWatch 指标和连接数 |
排查慢查询时，先执行：
db.orders.find({customerId:"A1001", status:"PAID"})
.sort({createdAt:-1})
.limit(20)
.explain("executionStats")重点看两件事：keysExamined 和 docsExamined。如果扫描量远大于返回量，说明索引虽然“存在”，但没有真正帮上忙。
二、索引“失效”最常见的 5 个场景
1. 字段顺序和查询条件不一致
比如你建的是 {customerId:1, createdAt:-1}，但查询只按 createdAt 过滤，再做排序，DocumentDB 很可能走不到这个索引。复合索引不是“有就行”，顺序要和过滤+排序习惯对上。
2. 字段类型不一致
这是我见过最多的隐性问题。库里存的是数字，代码里传的是字符串；或者字段一部分是时间戳，一部分是字符串日期。看起来条件没错，实际上索引命中率很差。
3. 用了不友好的查询写法
像前置通配符、$ne、$nin、大范围 $or、对未索引字段排序，这些都容易让扫描量暴涨。很多“索引失效”其实是查询形态不适合索引。
4. 只建了单字段索引，实际需要复合索引
高频场景通常不是“按一个字段查”，而是“先按租户、状态过滤，再按时间倒序取最近 20 条”。这种场景单字段索引经常不够，复合索引更稳。
5. 从别的 MongoDB 环境迁过来，代码没改
DocumentDB 虽然兼容 MongoDB，但不是把原环境原封不动搬过去就结束。你原来依赖的某些索引习惯、聚合写法、hint 方式，迁移后可能表现不同。迁移后第一件事不是上线，而是对照最慢的 20 条 SQL/Mongo 查询逐条验。
三、实际排查顺序：先看这 4 项，基本能定位 80% 问题
- 看执行计划：确认有没有走索引，扫描量是否异常。
- 看实例指标：CPU、内存、连接数、读写延迟是否同时升高。
- 看应用部署位置：应用和 DocumentDB 是否跨区、跨可用区、跨公网跳转。
- 看慢查询样本：不是看一条，而是看同类查询是否都慢。
如果你的应用服务器在新加坡，DocumentDB 在北美区域，单次网络往返就会把查询时间拉长。很多“数据库慢”其实是链路慢，尤其是高频小查询，体感更明显。
四、账号购买、实名认证、充值续费：这些事会直接影响你能不能顺利排查
AWS 国际站和国内云不一样，DocumentDB 通常不是“先充值再用”的模式，而是绑定有效支付方式后按量计费。所以你在排查性能前，得先确保账号状态正常，不然实例创建、扩容、快照恢复都可能卡住。
| 环节 | 常见卡点 | 实操建议 |
|---|---|---|
| 账号开通 | 邮箱、手机号、付款卡信息不一致 | 统一公司信息，别用来路不明的代开资料 |
| 实名认证/风控 | 新卡、小额扣款失败、频繁切换登录地点 | 先完成账单验证，再做资源创建 |
| 续费 | 卡过期、额度不足、发卡行拒绝 | 提前加预算告警，别等实例状态异常才处理 |
| 企业采购 | 发票抬头、税号、公司地址不一致 | 企业卡、企业邮箱、账单地址保持一致 |
如果你是通过代付、代开账号上云，最容易出问题的不是“能不能登录”，而是后面某次扣款失败后被触发审核。那时候不是简单换张卡就能解决，往往要补充账单证明、公司信息或联系 AWS Support。
五、支付方式差异：别把“充值”理解错了
- 信用卡/借记卡：最常见，但要注意发卡行风控，跨境扣款失败很常见。
- 企业卡：更稳，适合长期使用，但需要财务审批流程。
- 预付或代充：不建议作为长期方案，后续对账和风控解释成本高。
实际经验里，DocumentDB 的成本不是只看实例单价。你还要算：存储、IO、备份、跨区流量、只读副本、快照保留。如果查询慢导致你不断加实例，最终月账单会比你预期高很多。
AWS企业账号购买 六、成本对比：什么时候该继续救 DocumentDB，什么时候该换架构
| 方案 | 适合场景 | 成本特点 |
|---|---|---|
| 继续优化 DocumentDB | 已有 AWS 体系、数据结构稳定 | 改索引和查询成本低，适合短期止血 |
| 自建 MongoDB | 需要更高兼容性或特定特性 | 运维成本高，但可控性更强 |
| 迁移到其他托管 MongoDB | 对某些 MongoDB 行为依赖重 | 迁移成本高，先做 PoC 再决定 |
如果你的慢查询集中在 3~5 个核心接口上，先优化索引和查询写法，通常比直接换库更划算。只有当你确认是兼容性差异、功能限制或跨区延迟导致时，才考虑整体迁移。
AWS企业账号购买 七、我常见到的失败案例
案例1：电商订单查询，按 userId + status + createdAt 查最近订单，原来只建了 userId 索引。结果高峰期每次都扫大量历史数据。改成复合索引后，查询从秒级降到百毫秒级。
案例2：新开 AWS 账号后，DocumentDB 集群一直创建失败。最后发现是支付卡跨境验证没过，账号进入了审核状态，资源配额也没放开。先补齐账单验证，问题才真正解决。
案例3：应用部署在香港，DocumentDB 放在美国东部。数据库本身指标看着正常，但接口就是慢。把应用迁到同区域后，接口耗时直接下降一半以上。
八、你可以直接照着做的检查清单
- 先用
explain("executionStats")看是否真走索引。 - 核对字段类型，尤其是 ID、时间、状态值。
- 确认复合索引顺序和查询顺序一致。
- 检查应用和 DocumentDB 是否跨区。
- 确认 AWS 账号支付方式有效、未触发风控。
- 预算和告警先设好，避免因扣款失败导致资源异常。
FAQ
Q：索引明明建了，为什么还是慢？
大概率不是“没建”，而是查询条件没对上、排序没对上，或者字段类型不一致。
Q：AWS DocumentDB 需要像国内云那样先充值吗？
通常不是。更常见的是绑定信用卡/企业卡后按量扣费。支付失败会直接影响资源创建和续费。
Q：账号刚开通就被风控，怎么办？
先核对账单资料、卡片信息、登录地域是否一致，必要时准备公司证明和账单记录再提工单。
Q：慢查询要不要第一时间加机器？
不建议。先看扫描量和索引命中，很多时候加机器只是把问题延后，账单先涨起来。
如果你现在已经有具体慢查询语句，我建议先抓一条最慢的接口，把查询条件、索引定义、实例规格、部署区域一起对照。只要这四项对上，DocumentDB 的性能问题通常都能落到具体原因，而不是停留在“感觉很慢”。
