Search Indexer CPU 過高?重建索引與排除位置

文章屬性:疑難排除(A5 底層除錯)
適用系統:Windows 11(含 24H2/25H2)與 Windows 10
難易度 / 耗時:⭐⭐(方法三為 ⭐⭐⭐)/ 動手約 20 分鐘
核心結論:SearchIndexer.exe 吃 CPU 幾乎都不是「索引這件事」有問題,而是索引範圍被放大或索引被迫從頭重新掃描——這是兩種病,診斷錯了怎麼修都不會好。
適用對象:索引子長期佔用 CPU 或磁碟,關掉又怕搜尋失效的人

📌 快速答案

一句話答案:Search Indexer CPU 過高請依序做三件事——切回傳統索引模式並排除大量小檔目錄、用索引選項重建索引、確認重開機後不再從頭重跑。

🧰 開始前的準備

適用系統:Windows 11 全版本與 Windows 10。方法三與部分排查點在 Windows 11 較新版本上與舊教學不同,原因見下方「別再照抄舊教學」一節。
權限需求:方法一為一般使用者即可;方法二需要系統管理員;方法三需要系統管理員且會修改登錄檔。
需要工具:工作管理員、Windows 資源監視器(判斷是 CPU 還是磁碟瓶頸)、索引選項(control.exe srchadmin.dll)、登錄檔編輯器(僅方法三)。
預計耗時:排查與設定約 20 分鐘;重建索引本身無法用分鐘估算——微軟官方對首次索引的說法是「最多約兩小時(up to a couple hours)」,實際取決於檔案數量與儲存裝置。
先做的事:方法三動登錄檔前請先建立系統還原點,並把要改的機碼匯出備份(指令見該節)。

🔍 症狀描述與錯誤訊息

Search Indexer CPU 過高的典型畫面是這樣:工作管理員的「處理程序」分頁裡,Microsoft Windows Search 索引子(SearchIndexer.exe)長時間佔用可觀的 CPU,並伴隨持續的磁碟讀寫;風扇一直轉、筆電電池掉得比平常快,但你根本沒在搜尋任何東西。

常見的三種主觀描述,對應的其實是三種不同的病:

– 「剛裝完系統/剛升級完就一直跑」——這是初次建立索引,屬正常行為;官方對首次索引給的說法是「最多約兩小時」。
– 「每次開機都跑十幾分鐘,跑完就安靜」——這是索引被迫重新掃描,通常有觸發事件。
– 「一整天都在跑,永遠跑不完」——這才是真正的故障:索引範圍過大、某類檔案卡住,或索引資料庫本身損毀。

這裡沒有藍屏、沒有錯誤代碼,也不會跳任何對話框——Windows Search 出問題時最典型的表現就是「沒有錯誤訊息」,只有效能表現變差,加上搜尋結果開始漏東西。這也是它特別難查的原因:你得從行為反推,而不是從錯誤碼查起。

順帶提醒,如果你的機器同時還有 Recall、語意搜尋等背景 AI 負載在跑,那是另一條線,先看Windows 11 25H2 變慢?關閉背景 AI 負載教學排除掉,再回來讀這篇。

🔎 問題根因

先給結論:索引子本身有完整的節流機制,正常情況下你不該感覺得到它。 微軟官方文件明載,Windows Search 首次安裝時會對「檢索範圍(crawl scope)」做一次完整索引,並在高 I/O 與使用者活動期間暫停。換句話說,你會持續感覺到它,代表下列四件事之一發生了:

索引範圍被放大。Windows 11 的搜尋設定有「傳統」與「增強」兩種模式:傳統模式預設只索引文件、圖片、音樂資料夾加上桌面;增強模式索引整台電腦,包含所有使用者資料夾與檔案。切到增強模式,索引工作量會直接跳一個量級。
索引裡塞了不該塞的東西。官方給的經驗法則是索引大小約為被索引檔案大小的 10% 以內;但同一份文件也寫明,如果有大量極小檔案(小於 4 KB)或正在索引程式碼,索引大小會與檔案大小不成比例地暴增。開發者的 node_modules、build 輸出目錄、Git 物件資料夾正是這種結構。微軟支援文件(KB 4558579)還給了很少人引用的量化門檻:一般使用者的電腦索引項目通常少於 30,000 項、進階使用者可達 300,000 項,而「超過 400,000 項就可能開始出現效能問題」;索引子最多能處理約 100 萬項,再往上就可能失敗或造成 CPU、記憶體、磁碟空間的資源問題。 這條門檻是本文所有建議的量化依據——你要做的其實就是把項目數壓回門檻以下。
索引被迫從頭重來。NTFS 磁碟區只做一次完整檢索,之後全靠 USN 變更日誌通知增量更新;通知機制一旦失效(日誌輪替、服務被強制終止),gatherer 就會重新來過。
索引資料庫或某個 filter 出問題。官方把這件事拆成兩種後果:filter 效率不佳 → 索引過程會「急遽變慢」;filter 或 property handler 直接失敗 → 索引子根本無法索引該筆資料。前者表現成永遠跑不完的迴圈,後者表現成某些檔案永遠搜不到。

這四條的處置方式完全不同,所以本文的順序是「先分辨、再動手」,而不是一上來就叫你重建索引。

🔬 底層機制:CPU 是被誰吃掉的?

一句話:被 gatherer 排出來的佇列吃掉的。 微軟 Win32 文件把索引拆成三個階段,全部由一個叫 gatherer 的元件統籌:

階段一:把 URL 排進佇列。gatherer 蒐集資料存放區的變更資訊,和已知的檢索範圍比對,產出待處理的 URL 佇列。佇列有三條——高優先權通知、一般通知、定期檢索;通知佇列會排在檢索佇列之前處理,每條佇列內部依先進先出取用。
階段二:實際爬 URL。gatherer 依協定找到對應的 protocol handler,把它實體化在 搜尋協定主機(SearchProtocolHost) 裡。系統通常會開兩個協定主機處理程序,一個跑在系統安全內容、一個跑在使用者安全內容,避免使用者資料落到系統內容執行。
階段三:更新索引。gatherer 依副檔名、MIME 類型或 CLSID 找到對應的 filter(IFilter),把檔案串流餵進去,由 filter 吐出內容、由 property handler 吐出屬性,最後寫進名為 SystemIndex 的索引。

Search Indexer CPU 過高的四段分診流程:先分辨階段、再看範圍、再看通知機制、最後才重建

理解這三階段,才看得懂兩個關鍵事實:

第一,filter 是跑在你電腦上的第三方程式碼。 官方在「給實作者的建議」裡寫得很直白:因為每次遇到該檔案格式就會呼叫一次 filter,filter 若效率不佳,整個索引過程會急遽變慢。Windows 也為此設計了保護——filter 主機以最低權限執行、會被定期回收,而且當某個 filter 消耗過多資源時,主機處理程序會被回收掉。你在工作管理員裡看到 SearchFilterHost.exe 反覆出現又消失,通常就是這件事在發生。裝了 PDF、壓縮檔、CAD 的第三方 IFilter 的機器,特別容易踩到。

第二,NTFS 只爬一次,之後全靠通知。 官方把資料來源分成兩類:僅通知型(notification only)與通知啟用型(notification enabled)。NTFS 與 Microsoft Outlook 屬於前者——初次檢索完成後就不會再做完整檢索,除非發生失敗,例如 USN 變更日誌輪替(rolling over);Internet Explorer 與 FAT 屬於後者,索引子啟動時會做一次增量檢索。

這條直接解釋了最常見的困惑:「為什麼每次開機都要跑一次?」——在健康的 NTFS 系統上,這不該發生。它會發生,代表通知鏈斷過:USN 日誌被填滿而輪替、Windows Search 服務非正常終止、或磁碟區被以不保留日誌的方式重掛。找到讓通知鏈斷掉的原因,比重建索引一百次都有用。

還有一個很少被提到的反向排查點:backoff

Windows Search 有一個「索引子退讓(indexer backoff)」機制:系統活動高的時候降低索引速度,活動降低後再自動全速。微軟的 Policy CSP 文件裡有一個對應政策 DisableBackoff,說明寫得很清楚:啟用後索引子退讓機制會被停用,即使系統活動很高,索引仍會全速進行;而預設值是 0(停用該政策,亦即退讓機制生效)。

它對應的登錄檔位置是:

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Windows Search

值名稱為 DisableBackoff。群組原則的位置在「電腦設定 → 系統管理範本 → Windows 元件 → 搜尋 → Disable indexer backoff」,由 Search.admx 提供,Windows 10 1607 版起適用。

為什麼要查它? 因為有些「加速 Windows 搜尋」的教學、以及部分號稱最佳化的第三方工具,做的就是把這個值打開。打開之後索引確實變快,代價是它會在你正在用電腦的時候全速跑——症狀和「索引子失控」一模一樣。查一行就知道有沒有被動過:

Get-ItemProperty -Path 'HKLM:\SOFTWARE\Policies\Microsoft\Windows\Windows Search' -Name DisableBackoff -ErrorAction SilentlyContinue

沒有輸出 = 沒被設定過(正常);輸出 DisableBackoff : 1 = 有人關掉了退讓機制。

⚠️ 別再照抄舊教學:三個已經過時的做法

這一節是本文和多數中文教學最大的差異,建議先看完再動手。

過時一:msdt.exe -ep SystemSettings_Troubleshoot_L2 -id SearchDiagnostic

大量教學仍在推薦這條「搜尋與索引疑難排解員」指令。但微軟已公告淘汰 Microsoft 支援診斷工具(MSDT)與其上的內建疑難排解員,官方公布的時程是:2023 年開始把部分疑難排解員轉址到新的「取得協助」平台、2024 年完成轉址並移除其餘項目、2025 年移除 MSDT 平台本身。更關鍵的是——官方文件把疑難排解員分成「轉址」與「移除」兩張清單,而「Search and Indexing(搜尋與索引)」被列在「移除」那張清單裡,不是轉址。換句話說,它一旦生效就不會在「取得協助」裡復活。

但這裡要非常小心地講清楚兩件事,別跟著網路上「這招已經沒用了」的斷言走:

微軟在同一份淘汰公告裡寫的是「將於下一個 Windows 11 版本生效,日期待定」——官方到查證日為止仍未公布確切生效版本。
更矛盾的是,微軟 Learn 的《Fix problems in Windows Search》(查證日顯示 2026-02-12 更新、適用所有受支援的 Windows 用戶端)至今仍在教使用者執行搜尋與索引疑難排解員,其列出的指令形式是 msdt.exe -ep WindowsHelp id SearchDiagnostic。

官方同時載明:Windows 11 22H2 及更早版本、Windows 10、Windows 8.1、Windows 7 不受此淘汰影響。所以正確的說法不是「這招沒用」,而是「以你自己機器上實際看不看得到為準」:到設定 → 系統 → 疑難排解 → 其他疑難排解員看一眼,有就用、沒有就往下走方法一。兩份官方文件互相打架時,實機畫面才是唯一可靠的判準。

過時二:「去刪掉 Windows.edb 就好」

這是流傳最廣、也最容易讓人白忙一場的一條。Windows.edb 是 ESE 資料庫格式的索引檔,位於 C:\ProgramData\Microsoft\Search\Data\Applications\Windows\。問題是——數位鑑識研究指出,自 Windows 11 起,Windows Search 已改用 SQLite,單一的 ESE 資料庫被 Windows.db 與 Windows-gather.db 取代(該分析另提到 Windows-usn.db),路徑仍是同一個資料夾。

⚠️ 事實類型標註(請連這段一起讀,兩段話的證據等級不一樣):「檔名換了」這件事有微軟官方背書——支援文件 KB 4558579 在教你怎麼看索引資料庫大小時,直接寫成「*Windows.edb*(Windows 10)或 *Windows.db*(Windows 11)」,路徑同樣是 C:\ProgramData\Microsoft\Search\Data\Applications\Windows。但「內部改用 SQLite、拆成多個 db 檔」屬第三方研究,而且只有一份——來源是 Stroz Friedberg(Aon 的數位鑑識部門)的鑑識分析,LevelBlue 站上那篇為同一份研究的轉載,不是第二個獨立驗證,請不要把它當成雙來源。同一份研究另把 Windows Server 2008 到 Windows Server 2022 歸類為與 Windows 10 相同的 ESE 結構,所以這條只能說到用戶端 Windows 11,伺服器版本不在此列。

實務上的意義很單純:在 Windows 11 上照舊教學去找 Windows.edb,通常根本找不到這個檔案——照抄那類教學等於白忙一場。若你的機器上仍看得到它,請先確認它是否還在被服務使用,不要直接刪。而且直接刪資料庫檔本來就不是好做法——正規流程是用索引選項的「重建」,讓服務自己收尾。

過時三:「乾脆停掉 Windows Search 服務」

停掉 WSearch 服務確實能立刻讓 CPU 降下來,但代價比多數人以為的大:官方文件寫明,檔案總管用索引來存取與追蹤檔案變更、Microsoft Edge 用它提供網址列的瀏覽記錄結果、Outlook 離線模式用它搜尋郵件。停掉之後這些功能全部退回逐檔掃描,「開始功能表搜尋變超慢」只是最表面的那一層。把它當永久解法之前,先試完下面三個方法。

🛠️ 解決方案

⚠️ 執行前請先確認:方法三會修改登錄檔並清掉你自訂的索引位置。動手前請先建立系統還原點(設定 → 系統 → 系統保護 → 建立),並依該節指示匯出機碼備份。若方法一或方法二已經解決,就不要往下做——沒有必要為了「做得更徹底」去動登錄檔。

方法一:縮小索引範圍(成功率最高,零風險)

先從代價最低的做起。多數 Search Indexer CPU 過高的案例,在這一步就結束了。

步驟 1|確認目前是哪種模式。 到設定 → 隱私權與安全性 → 搜尋 Windows(部分版本顯示為「搜尋」),看「尋找我的檔案」是「傳統」還是「增強」。官方對兩者的定義是:傳統模式預設索引文件、圖片、音樂資料夾加上桌面;增強模式索引整台電腦。如果你是增強模式又覺得索引一直在跑,先改回傳統。

步驟 2|把吃資源的目錄排除掉。 ⚠️ 先注意一個前提:官方文件在講到「自訂搜尋位置」時,三處都寫成「在傳統模式下」——若你目前是增強模式,得先切回傳統模式,這個入口才會出現。切好之後,在同一頁點「自訂搜尋位置」開啟索引選項,按「修改」,取消勾選不需要被搜尋的位置。優先排除這幾類:

開發專案目錄(node_modules、vendor、.git、build/dist 輸出)
虛擬機器磁碟檔、Docker 資料目錄
遊戲安裝目錄與大型素材庫
已有自己搜尋機制的軟體資料夾(郵件客戶端資料庫、筆記軟體同步目錄)

為什麼是這幾類? 回到官方那條規則:索引大小通常在被索引檔案的 10% 以內,但大量小於 4 KB 的檔案或程式碼會讓索引大小不成比例地暴增。上面每一類都精準命中「檔案極多、單檔極小、而且你根本不會用 Windows 搜尋去找它」。

步驟 3|把不需要的檔案類型改成只索引屬性。 索引選項 → 進階 → 檔案類型分頁,選中檔案類型後,把「僅索引屬性」與「索引屬性和檔案內容」二選一。官方明講:只索引屬性不會讀取檔案內容,索引會變小,但檔名以外的內容就搜不到了。原始碼副檔名(.js、.ts、.py、.json、.log)改成僅索引屬性,通常立刻有感。

步驟 4|順手檢查兩個容易被忽略的政策。 若這台機器被 IT 或某個最佳化工具動過群組原則,以下兩項會直接影響索引行為:

政策	官方說明重點	影響
`DisableBackoff`	預設為停用;啟用後即使系統忙碌,索引仍全速進行	被打開就會「你在用電腦時它也在全速跑」
`AllowIndexingEncryptedStoresOrItems`	這項設定啟用或停用時,索引會被完整重建	被切換過,就會看到一次無來由的全量重建

第二條特別值得記住:它不是「壞掉了」,是政策改動的正常副作用。企業機器上這是很常見的誤判來源。

方法二:重建索引(內建 UI 做法)

方法一無效,或搜尋結果已經開始漏檔案(索引損毀的典型徵兆),才做這一步。

執行 control.exe srchadmin.dll 直接開啟索引選項(比一層層點設定快)。
按「進階」→「疑難排解」區塊 →「重建」。
系統會提示重建期間搜尋結果可能不完整,確認即可。

重建要跑多久? 這裡有兩個不同的官方數字,別搞混:首次索引的說法是「最多約兩小時(up to a couple hours)」;而重建索引資料庫,微軟支援文件(KB 4558579)給的是「讓索引子跑最多 24 小時」。實際落在哪裡,取決於項目數、儲存裝置類型與你有沒有一直在用電腦(退讓機制生效時會刻意慢下來)。筆電請插電再做——官方在 Copilot+ PC 的說明裡特別建議首次索引時插上電源,狀態訊息也有一條就叫「索引已暫停以節省電池電力」。

重建期間該預期什麼: 開始功能表搜尋、檔案總管搜尋、Outlook 離線搜尋都會暫時不完整,這是正常的。停止條件:若重建進行超過 24 小時且「已索引項目數」完全沒有增加,代表卡住了,請停止等待並往下一步。

⚠️ 補充:官方其實有兩條路。「重建」不只是內建 UI,微軟支援文件(KB 4558579)也明確記載了它——Windows 11 的路徑寫成「設定 → 隱私權與安全性 → 搜尋 Windows → 進階索引選項 → 進階 → 重建」,和上面的 control.exe srchadmin.dll 是同一個對話框。另一條官方路是 PowerShell 腳本 ResetWindowsSearchBox.ps1,由微軟下載中心提供(《Reset Windows Search PowerShell script》,下載中心編號 100295),須以系統管理員身分執行。兩條都試過還是不行,才輪到方法三動登錄檔——官方有背書的做法,風險永遠比自己改登錄檔低。

方法三:重設 Windows Search 設定(⭐⭐⭐ 涉及登錄檔)

⚠️ 高風險操作警語:本節會修改 HKEY_LOCAL_MACHINE 底下的登錄檔值。改錯位置可能導致搜尋功能異常或系統設定錯亂。請務必先完成備份步驟,並確認你已經試過方法一與方法二。不確定就不要做——把機器交給懂的人,永遠比改壞了再救便宜。

步驟 1|備份(不可跳過)。 先建立系統還原點,再用系統管理員身分的命令提示字元匯出機碼:

reg export "HKLM\SOFTWARE\Microsoft\Windows Search" "%USERPROFILE%\Desktop\WindowsSearch-backup.reg"

確認桌面上出現該 .reg 檔再往下。

步驟 2|停止搜尋服務。

net stop wsearch

步驟 3|把 SetupCompletedSuccessfully 改為 0。 用登錄檔編輯器展開到:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Search

找到 SetupCompletedSuccessfully,把值由 1 改成 0。

這一步在做什麼? 依 Winhelponline 的整理,把該值由 1 改為 0 之後重新開機,Windows Search 會清除自訂的索引位置、加回預設位置,並從頭重建索引。⚠️ 事實類型標註:這是第二級來源的社群整理做法,微軟並未提供對應的官方說明文件;請把它理解成「已被廣泛驗證但無官方背書」的手段,這也是它排在方法三、而不是方法一的原因。

步驟 4|重新開機。 不要只是重啟服務——這個值是在服務初始化時讀取的。

⛔ 停止條件(符合任一即停手,改走回退):

匯出備份失敗或找不到 .reg 檔 → 停手
展開後找不到 SetupCompletedSuccessfully 這個值 → 停手,不要自己新建
改完重開機後搜尋完全失效超過 24 小時 → 停手,執行回退

✅ 驗證修復結果

別只看「CPU 掉下來了」——那可能只是索引卡住不動。三項一起看才算數:

索引有在推進:開啟索引選項,觀察「已索引 N 個項目」。健康狀態下這個數字會持續上升,最後停在一個穩定值並顯示「索引完成」。
CPU 在閒置時歸零(有前提):必須先等索引選項顯示「索引完成」,再把電腦放著不動 10 分鐘,SearchIndexer.exe 的 CPU 才應該接近 0%。⚠️ 索引還沒建完時,閒置反而是它全速工作的時機——官方的節流設計就是「系統忙碌時降速、閒下來就補回進度」,所以這個階段閒置衝高屬正常,不是故障。
搜尋真的能用:到檔案總管搜尋一個你確定存在、且位於索引範圍內的檔名關鍵字,結果要立刻出現。搜不到 = 索引還沒建完或範圍被排除掉了。

最關鍵的一項是「重開機後不再重跑」。 依前面的機制,NTFS 初次檢索完成後就該靠 USN 通知增量更新。如果重開機後又從頭跑,代表通知鏈仍然是斷的,索引重建再多次也沒用,該回頭查磁碟健康度與 Windows Search 服務是否被其他程式強制終止。

🔙 萬一翻車:回退步驟

情境一:改完之後搜尋完全失效。

用系統管理員身分執行,匯入你在方法三步驟 1 匯出的備份檔:

reg import "%USERPROFILE%\Desktop\WindowsSearch-backup.reg"

接著重新開機。請用備份檔還原,不要手動把值填回 1——你的原始值不一定是 1,備份檔才是這台機器的真實原值。

情境二:自訂的索引位置被清光了。

這是方法三的預期副作用(它本來就會清除自訂位置並加回預設)。到索引選項 → 修改,把你原本加過的位置重新勾選回來即可,無須重跑任何指令。

情境三:服務起不來、系統整體異常。

使用方法三步驟 1 建立的系統還原點還原;若連還原點都不可用,請不要繼續嘗試各種登錄檔偏方,改用官方修復管道處理。

💡 總結:預防再次發生

站長我在處理這類「沒有錯誤訊息的效能問題」時,養成的第一個習慣是先問「它在做的事情合不合理」,而不是先問「怎麼把它關掉」。Search Indexer 是這個習慣最好的教材:它有完整的節流設計、有官方文件寫清楚的三階段流程、也有明確的「只爬一次」承諾;當你持續感覺得到它,幾乎一定是有人(或某個設定)讓它偏離了設計。

第一,把索引範圍當成需要維護的東西。 新增開發專案、裝新遊戲、接新的外接硬碟之後,順手看一眼索引位置。

第二,對「最佳化工具」保持警覺。 DisableBackoff 這種政策被打開,症狀和故障一模一樣,但原因在人不在系統。這不是站長多心——微軟支援文件自己就寫了:部分防毒軟體與「最佳化你的 PC」類應用程式會停用 Windows Search 服務,官方的建議是別跑那類程式,不然就在跑完之後回頭檢查服務狀態。

第三,別把「停用服務」當成解法。 檔案總管、Edge 網址列、Outlook 離線搜尋都吃這個索引;把它停掉是用三個功能換一個安靜。真的要停,也請先確認你不用這三樣。

最後一個提醒給台灣讀者:微軟官方文件明載,改良後的搜尋(語意 + 詞彙)目前只針對英文、法文、德文、西班牙文、日文與簡體中文最佳化,其餘語言一律走傳統詞彙式搜尋。也就是說,繁體中文內容在現階段拿不到語意搜尋的好處——你為繁中文件付出的索引成本,換回來的仍然是傳統關鍵字比對,所以「精準縮小索引範圍」對台灣使用者的性價比更高。

❓ 常見問題

Q:直接停用 Windows Search 服務可以嗎?

可以,CPU 會立刻降下來,但官方文件明載檔案總管用索引存取與追蹤檔案變更、Microsoft Edge 用它提供網址列的瀏覽記錄結果、Outlook 離線模式用它搜尋郵件——這三項會一起降級。建議先做完方法一,通常就不必走到停用。

Q:重建索引會不會刪掉我的檔案?

不會。重建的是索引資料庫,不是你的檔案。索引本身只是檔案屬性與內容的目錄,重建期間唯一的影響是搜尋結果暫時不完整。

Q:為什麼我在 Windows 11 上找不到 Windows.edb?

檔名換了,這點微軟官方文件有寫:KB 4558579 直接把索引資料庫寫成「*Windows.edb*(Windows 10)或 *Windows.db*(Windows 11)」。至於「內部改用 SQLite、拆成 Windows.db 與 Windows-gather.db 等多個檔」則出自一份第三方鑑識研究(僅單一來源),伺服器版本(至 Windows Server 2022)則仍為 ESE 結構。若你的機器上仍看得到 Windows.edb,請先確認它是否還在被服務使用,不要直接刪除。

Q:Copilot+ PC 的語意索引會讓情況更嚴重嗎?

它是額外的索引工作,官方也明說語意索引在 Copilot+ PC 上預設啟用,並建議首次索引時把裝置插電。若你的機器是 Copilot+ PC 且剛開箱或剛大版本更新,插電放著跑完是最省事的做法。

Q:修完之後又復發怎麼辦?

先確認是不是「重開機就重跑」——若是,問題在通知鏈而非索引本身,請查磁碟健康度、USN 變更日誌是否被填滿、以及 Windows Search 服務有沒有被第三方軟體強制終止。若是「新增某個目錄後復發」,回方法一把該目錄排除即可。

🔗 延伸閱讀

Win10/Win11 固態硬碟 SSD 效能最佳化技巧——索引的磁碟寫入是否合理,得先知道你的 SSD 在正常狀態下是什麼表現。
Win10/Win11 系統還原點完整教學:開啟、建立、還原與失敗排錯——方法三動登錄檔前必備的那道保險,這篇教你怎麼確認它真的有在運作。
Windows 11 變慢、卡頓怎麼辦?2026 全方位系統加速優化指南——確認不是索引子的問題之後,往這裡繼續找其他拖慢系統的來源。
Windows 工作管理員終極指南:揪出資源怪獸與效能瓶頸——排查第一步就是看懂工作管理員在告訴你什麼,這篇把欄位一次講完。

📎 參考資料來源

📖 第一級|廠商官方:

Search indexing in Windows(Microsoft Support) — 2026-08-26 查證
Indexing process in Windows Search(Microsoft Learn, Win32) — 2026-08-26 查證
Policy CSP – Search(Microsoft Learn) — 2026-08-26 查證
Deprecation of Microsoft Support Diagnostic Tool (MSDT) and MSDT Troubleshooters(Microsoft Support) — 2026-08-26 查證
Fix problems in Windows Search(Microsoft Learn) — 2026-08-26 查證
Troubleshoot Windows Search performance(Microsoft Learn,KB 4558579) — 2026-08-26 查證
Reset Windows Search PowerShell script(Microsoft 下載中心,編號 100295) — 2026-08-26 查證

📖 第二級|權威技術與研究來源:

Windows Search Index: The Forensic Artifact You’ve Been Searching For(LevelBlue,Stroz Friedberg / Aon 原研究之轉載版) — 2026-08-26 查證。本文查證時 Aon 原文網址(cyber.aon.com)回傳空白、無法直接取得,故以此轉載版比對;兩者為同一份研究,不構成雙來源。
How to Reset & Rebuild Windows Search Index Completely(Winhelponline) — 2026-08-26 查證

⚠️ 本文核心事實以第一級為準,第二級為補充;Windows.db 之內部格式(單一第三方來源)與 SetupCompletedSuccessfully 兩項已於內文標明為非官方來源(檔名本身則有 KB 4558579 官方佐證)。

📅 本文查證戳記:2026-08-26 依微軟官方文件與 Windows 11 現行行為撰寫,全文為官方文件交叉查證(E3),未包含第一手實測數據。
若你在後續版本遇到步驟失效,歡迎在留言區回報,站長會更新文章。