Windows の検索インデクサーが何時間も CPU を食う理由

SearchIndexer.exe が午後いっぱい CPU コアを焼いているのは故障に見えますが、ほとんど常に追い上げ作業です。ディスクで大きな出来事があったあと、インデックス作成を待つファイルの山が溜まっただけです。解決策はサービスと戦うことではなく、キューに投入し続ける元凶を見つけることです。

バグではなくバックログ

インデクサーは NTFS の USN 変更ジャーナルを追うため、大規模なファイル操作はすべてインデックス作業になります。システムボリュームを再パースする Windows の機能更新、数千のファイルを引き下ろす OneDrive や Teams の同期、復元されたバックアップ、開発者の新しい node_modules ツリー。それぞれが数十万単位の項目をキューに入れられます。1 項目のインデックス化は安価ですが、数十万項目は数時間かかり、タスクマネージャーで見ているのはまさにそれです。

もう一つの定番は Outlook です。巨大な .pst や .ost アーカイブは同じパイプラインで 1 件ずつインデックス化され、20 GB のメールアーカイブはインデクサーを営業時間の大半にわたって占有できます。「インデックスのオプション」を開いて状態行を読みましょう。「残り項目」の膨大なカウンターと増え続けるインデックス済み総数は、バックログを捌いている健康なインデクサーを意味します。カウンターがまったく動かない、あるいは CPU が高いままデータベースが馬鹿げたサイズに膨らむ場合は、ループで再構築を繰り返す破損インデックスの兆候で、「再構築」ボタンが必要になる唯一のシナリオです。

大きな .pst や .ost を抱えるクラシック Outlook — 同じサービスによる 1 件ずつのインデックス化
数千のファイルをマシンに引き下ろす OneDrive、Teams、バックアップの復元
システムボリュームを再パースしてインデックスを再検証する Windows 機能更新
開発者ツリー:数万の小さなファイルを含む node_modules、ビルド出力、.git フォルダー
すべてのメタデータに触れてディスク全体を再キューイングするファイルスキャンツール
再構築と肥大化を繰り返す破損した Windows.edb または Windows.db インデックス

検索を壊さずにインデクサーを手なずける

効く一手はサービス制御ではなくスコープ制御です。「インデックスのオプション」で「変更」を押し、検索しないツリーのチェックをすべて外します — ビルドフォルダー、メディアアーカイブ、ダウンロードのたまり場 — そして変更が落ち着くのを待ちます。クラシック Outlook のアーカイブについては、かつてマウントした .pst すべてではなく、実際に検索するストアだけをインデックス化します。スコープを変えたあとは、インデクサーに一晩あげましょう。夕方 6 時に無限に見えたキューも、朝には終わっていることが多いのです。

CPU スパイク解消のために検索サービスを無効化してはいけません。インデックスが切れていると、エクスプローラーのインデックス対象ロケーション検索、スタートメニューの結果、Outlook 検索がすべて遅いクロールモードへ転落し、サービスを再度有効化した瞬間にバックログも再開されます。インデックスが本当に破損している場合 — ループ再構築の症状 — は、「インデックスのオプション」の「詳細設定」と「再構築」でデータベースを一度削除して育て直します。一回限り数時間の CPU を払い、ループを断ち切れます。同時ユーザーの多いサーバーでは、インデクサーがユーザーごとに走ることを思い出してください。SearchIndexer.exe の複数インスタンスは、複数の独立したバックログです。