MongoDb CPUの利用率が高すぎる問題はどう解決しますか？

会社のプロジェクトの中で、突然1つの情況が現れたことがあって、mongodbのCPUの利用率は100%に達して、サーバーのこちら側のカードが死にました。
当時、APPユーザーはある時間帯に集中して使うかもしれないので、要求量は一気に上がってしまいました。ちょうどAPPが要求を開けた時、一つのモンゴdbの要求があります。
当時はMongodbのサーバーが私達のところにないので、一気に反応しませんでしたが、最後は排除して解決しました。ここでは検査と解決の全過程を記録します。
問題の分析:
1.コードによって、Mongodbのエラーとして位置づけられました。
2.Mongodbサーバの監視バックに入る。ここはアリ雲で購入したクラウドキャッシュです。

3.Mongodbが問題があると分かったら、やりやすくなります。アリ雲の中に索引の推薦があります。使いやすいのは、調査時間、実行回数、オススメの策略を提供します。

はい、ここの準備はほぼ終わりました。
解決策:
1.これらの実行回数と実行時間が遅いので、ライブラリを見に行きました。設計上、問題があります。一つの倉庫には900 Wのデータがあります。そして、集合ロジックを見て、この倉庫は中だけにデータを保存して、整理しません。
2.インデックスが確立されていません。単一のインデックスと連結インデックスが含まれています。これも遅い原因の一つです。最適化後はこのようになります。
db.get Collectionstudyhistory'）.createIndex(''studentId':1，'contentStudyID':1，'courseWareID':1，'courseStudyId':1))
3.一つの検索総数の方法に問題があります。以下は修正後のJAVA方法です。

MongoCollection<Document> collection = database.getCollection(pushMessageCollection);
 
long cNt = collection.count(Filters.and(Filters.eq("userId", userId),
                    Filters.eq("sendType", sendType),
                    Filters.eq("message_read", "0")));

最初の書き方は大体タイプです。Mysqlで、あるリストを調べて、そしてlist.size()を合計して、
修正後の方法：count（id）の総数に相当します。
そうすれば、修正後の方法はきっと修正前より早いと思います。
プランは基本的に決まっています。実施後に圧力テストを開始します。
修正されていない時の2000合併：

修正後の2000合併：

時間が見られますし、明らかに向上しました。
そして4000の合併をテストして、遅くなりましたが、崩れませんでした。

CPU情報を調べたら、100%の状況が出ていません。

以上が本文の全部です。皆さんの勉強に役に立つように、私たちを応援してください。