crud性能骤降主因是底层执行路径变更而非代码改动：索引失效、聚合降级为join、bson解析偏差或驱动走兼容层非原生协议；典型表现为基础操作正常但聚合延迟飙升，需检查协议直通配置、执行计划是否含hash join/materialize、驱动版本及bson类型处理差异。
直接看结论：CRUD性能突然下降，90%以上不是代码改了，而是底层执行路径变了——比如索引失效、聚合降级为多表JOIN、BSON解析偏差导致额外序列化开销，或者驱动实际走的是兼容层翻译而非原生协议直通。
连接后基础CRUD正常但聚合变慢
这是最典型的“表面连通、实际降级”现象。Java或Node.js客户端能insertOne、findOne成功，但一跑$group或$lookup就延迟飙升，监控显示连接池频繁超时或CPU空转。
- 先确认是否真走MongoDB协议直通：检查金仓侧配置是否启用
enable_protocol_compat=on且extension_protocol_port=27017开放；若应用仍连localhost:5432（默认PostgreSQL端口），说明驱动根本没进兼容模块 - 查执行计划：在金仓中执行
EXPLAIN对应聚合语句，看是否出现Hash Join或Materialize节点——这代表被转译成关系模型执行，而非文档引擎原生处理 - 注意驱动版本：MongoDB Node.js Driver v5.0+支持自动协商协议，但v4.x默认走旧版BSON解析，容易触发
BSON decode error并回退到低效fallback路径
响应时间从300ms跳到2s，但CPU/内存无异常
这种“资源不涨、耗时翻倍”的情况，基本锁定在执行策略切换上。福建某电子证照平台就因此卡了三天，最后发现是$project里用了$dateToString，而兼容层未实现该操作符的流式计算，被迫把整个结果集加载进内存再格式化。
- 逐段注释聚合管道：从
$match开始，每加一个stage就测一次耗时，定位首个性能拐点stage - 对比小数据集与大数据集行为：很多兼容实现对
$facet或嵌套$unwind有缓存阈值（如50万条触发中间态截断），小数据下没问题，压测才暴露 - 检查时间字段处理：原MongoDB的
ISODate("2024-01-01T00:00:00Z")在导入后可能变成字符串或精度丢失的TIMESTAMP，导致$gt查询无法走索引
同一套代码，Java稳、Node.js偶发失败
这不是语言问题，是BSON扩展类型支持粒度差异。Node.js Driver对ObjectId、Decimal128等类型更敏感，而Java Driver常通过BasicDBObject做弱类型兜底，掩盖了底层解析偏差。
- 抓包验证：用Wireshark过滤
port 27017，比对Java和Node.js发出的BSON二进制流，重点看0x07（ObjectId）、0x13（Decimal128）字节是否存在或被替换成0x02（String） - 禁用自动类型推断：Node.js中显式指定
useBigInt64: true和promoteLongs: false，避免Driver把Int64误转为JS number导致精度丢失 - 绕过驱动：直接用curl向金仓
/api/v1/mongo/query（如有HTTP接口）提交原始BSON hex，验证是否为驱动层问题
真正棘手的从来不是“查不到数据”，而是“查得差不多但不准”——比如$group输出数组顺序错乱、$sum结果差几条记录、$lookup关联后丢失部分子文档。这些细微偏差往往只在业务报表核对时才暴露，排查窗口极短，必须在迁移前就用真实数据集跑通全量聚合用例，而不是只测单条CRUD。
