磁碟使用率都 100% 了，為什麼只有幾 MB/s？

因為磁碟處於使用中的時間，和每秒能傳輸的位元組數是兩種不同的指標。細碎的讀寫與 I/O 的等待時間，會讓傳輸量不大卻依然很忙。請確認目標磁碟的回應時間，以及緩慢的操作是否同時發生。

停用 SysMain 一定會變快嗎？

不能說一定會變快。請先維持一般設定，只有在懷疑與 SysMain 有關時，才在記錄下原本狀態之後，比較暫時停止與重新啟動的差別。是否永久停用，不要只憑這一次比較就決定。

Windows Search 可以停掉嗎？

它會影響仰賴搜尋索引的搜尋速度與結果的更新，所以不要把它當成第一個對策。請先確認索引的進度；如果有不需要的資料夾被納入搜尋範圍，應優先考慮檢視這個範圍。

可以關掉 Defender 來降低磁碟使用率嗎？

不建議把關閉即時保護當成日常的加速手段。請用 Microsoft Defender Antivirus 的效能分析器記錄掃描的負擔，查明與哪些檔案或處理有關。報告中排在前面的項目，也不能就這樣加入排除設定。

磁碟使用率 100% 要停掉什麼才會好？──分辨 SysMain、Windows Search 與 Defender

2026年09月05日 04:00 · 更新日期: 2026年09月08日 · Go Komura · Windows 11, 效能, 故障排查, SysMain, Windows Search, Microsoft Defender, PowerShell

打開工作管理員一看，磁碟 100%。開應用程式慢，打字也慢。這時如果查到「停用 SysMain」「停止 Windows Search」「關閉 Defender」這些做法，就會很想乾脆全部停掉。

但這裡要分清楚的是，「是什麼在讀寫」和「為什麼操作會被卡住」。光看工作管理員上排在前面的名字，是分不出這兩者的。

本文主要寫給使用 Windows 11 電腦的一般使用者，說明畫面數值的讀法、這三個功能各自的職責，以及可以還原設定的調查步驟。畫面名稱與可用的功能會因 Windows 的組建與管理原則而不同。需要系統管理員權限的操作會明確標示。出處是 2026 年 9 月 5 日確認的 Microsoft 第一手資料。本文不是在特定實際設備上測量改善幅度的文章。

1. 先講結論：不要把三者一視同仁地停掉

本文建議的順序是：觀察 → 縮小範圍 → 只改一處 → 還原後比較。請先儲存重要檔案；如果是公司統一管理的電腦，更改設定前請與管理者討論。

功能	先看什麼	首先考慮的做法
SysMain	出問題的時段是否與該服務有關	通常維持原樣。只有在有依據時才比較暫時停止與重新啟動
Windows Search	索引的進度與搜尋範圍	檢視是否含有不需要搜尋的資料夾
Microsoft Defender Antivirus	掃描是否與緩慢的操作重疊	在維持保護的前提下記錄並分析

這張表並不是單純按「停掉有多危險」排出來的。SysMain 的職責是維持與改善系統效能，Search 是為搜尋建立索引，Defender 是防毒，三者各不相同。失去的功能也各不相同。¹²³

flowchart TB
    accTitle: 排查磁碟 100% 的基本順序
    accDescr: 看到磁碟 100% 後，先觀察緩慢的操作與對象，只比較一處更動並還原的順序。
    A["磁碟 100% 與操作變慢"] --> B["記錄時段與對象"]
    B --> C["嘗試一個假設"]
    C --> D["還原後再次確認"]
    D --> E["只留下必要的對策"]

圖 1: 在整批修改設定之前，先做出一個能拿來比較的狀態。

圖中實線表示始終成立的關係，虛線表示附帶條件的關係（成立條件寫在詳細頁面中各關係的說明中）。關係的完整清單（共 13 條，附依據與可信度）以及主要概念的定義，彙整在知識地圖詳細頁面（日文）。資料：JSON-LD / Turtle

2. 100% 既不是「容量已滿」，也不是「達到最高速度」

在工作管理員的「效能」中打開目標磁碟，可以看到使用中的時間、讀取與寫入速度、平均回應時間。忙碌時間的比例和實際搬運的資料量是兩回事。剩餘容量夠不夠，也需要另外確認。

舉例來說，如果每一筆處理都要等待，那麼即使一直在做事，推進的資料量也不會多。這就像「一次搬一個大箱子」和「一個一個遞小箱子」的差別。當讀寫很細碎，或儲存裝置那側有延遲時，就算只有幾 MB/s 也可能接近 100%。Microsoft 的效能調查資料中，除了傳輸量之外也會確認 I/O 的回應時間。⁴

因此，「既然 100% 就表示 SSD 的速度已經跑滿」和「只有幾 MB/s 所以磁碟不是原因」都下結論太早。首先要把出問題的磁碟編號與磁碟機代號對上再看。如果 C: 和 D: 在同一顆實體磁碟上，對 D: 的作業也可能與 C: 那側的操作互相競爭。

flowchart TB
    accTitle: 觀察磁碟的三個指標
    accDescr: 使用中的時間、傳輸速度、回應時間是不同的指標，要放在同一時段一起看。
    A["觀察同一時段"] --> B["忙碌程度：使用中的時間"]
    A --> C["處理量：讀寫速度"]
    A --> D["等待：回應時間"]
    B --> E["與操作的遲緩相互印證"]
    C --> E
    D --> E

圖 2: 光看百分比，無法分辨是處理量大，還是等待時間長。

3. 最初的觀察：什麼時候、在哪個檔案上變慢

先不要停服務，用 Ctrl + Shift + Esc 打開工作管理員。把「處理程序」裡的磁碟欄排序，同時在「效能」中確認對應的磁碟。再用 Win + R 啟動 resmon.exe，在資源監視器的「磁碟」中查看處理程序名稱、檔案、讀取、寫入與回應時間。如果看得到的資訊不夠，請委託系統管理員來調查。⁵

記錄要和具體作業綁在一起，例如「開機後 3 分鐘」「解壓縮 ZIP 的過程中」「直到同步結束」。本文建議的不是只看某一瞬間的畫面，而是把變慢之前、變慢期間、恢復之後放在一起比較。更新或複製正在進行、完成後就平靜下來的狀況，和同樣一個小操作每次都卡很久的狀況，接下來要查的東西並不相同。

另外，回應時間的平均值並不等於單次操作的最差值。不要只憑一個偶發的高數值就斷定是故障，要與能重現的停頓或錯誤相互對照。就算 System 或 svchost.exe 排在前面，也不要只憑名字就強制結束它們。System 還牽涉核心與驅動程式的處理。⁴

flowchart TB
    accTitle: 調查中要留下的觀察記錄
    accDescr: 以變慢的時刻與操作為起點，記錄磁碟、處理程序、檔案以及恢復時的條件。
    A["緩慢的操作與時刻"] --> B["確認對應的磁碟"]
    B --> C["查看處理程序與檔案"]
    C --> D["結束之後繼續觀察"]
    D --> E["記錄恢復時的條件"]

圖 3: 不只是「當時很卡」，還要留下能用來重現的記錄。

4. 看到了名字，和它就是根本原因，是兩回事

當一個會大量建立檔案的應用程式在跑時，除了該應用程式本身的寫入，還可能疊上搜尋索引的更新與安全性檢查。Search 會把檔案的資訊編入搜尋索引，Defender 則會對檔案與處理進行檢查。²⁶

接下來是為了思考原因而舉的例子。在解壓縮軟體大量建立檔案的過程中，即使 Defender 的負擔增加了，也不代表「只有 Defender 壞掉了」。檔案產生的頻率、目標資料夾、儲存裝置的回應可能都在一起發揮作用。

反過來說，因為是正規的 Windows 功能就斷定它無關，同樣是錯的。就算是必要的功能，在實際環境中也可能成為競爭因素。我們想知道的不是誰好誰壞，而是減少哪一類處理、減少多少，才能改善自己需要的作業。

flowchart TB
    accTitle: 一項作業引發多處讀寫的例子
    accDescr: 大量產生檔案時，若在搜尋範圍內則疊加索引更新，若在保護範圍內則疊加檢查。
    A["大量產生檔案"] --> B["應用程式本身的寫入"]
    A -.-> C["在搜尋範圍內則更新索引"]
    A -.-> D["在保護範圍內則進行檢查"]
    B --> E["可能在同一儲存位置競爭"]
    C --> E
    D --> E

圖 4: 虛線的處理並不表示每次一定發生，而是可供調查的候選關係。

5. SysMain：先維持原樣，只在有懷疑時做暫時比較

在 Microsoft 的服務清單中，SysMain 是以維持與改善系統效能為目的的服務，在那份資料裡被歸入不應停用的類別。不過資料的適用對象是 Windows IoT Enterprise，並不是「所有一般 Windows 11 電腦都一定會變快」的實測保證。¹

本文不建議只憑磁碟 100% 這個顯示，就把啟動類型改成「已停用」。停掉之後數字馬上下降，也可能只是背景的工作變少了。還要看打開應用程式花的時間，以及平常的作業是否有所改善。

在工作管理員中展開服務主機的群組確認關聯，只有在拿到懷疑 SysMain 的材料時，才以系統管理員身分做短時間的比較。停止之前，請用 services.msc 記下 SysMain 的狀態與啟動類型。暫時停止服務，和讓它下次開機也不啟動，是兩種不同的操作。⁷⁸

flowchart TB
    accTitle: SysMain 的暫時比較與永久停用的差別
    accDescr: 本次調查是把執行中的服務暫時停止再復原，與永久更改啟動設定分開處理。
    A["確認與 SysMain 的關聯"] --> B["記錄原本的狀態"]
    B --> C["若在執行中則暫時停止"]
    C --> D["比較同樣的操作"]
    D --> E["重新啟動並確認"]
    B -.-> F["不更改啟動設定"]

圖 5: 不要把「停下來看差異」和「一直停用」混為一談。

給系統管理員：把 90 秒比較與復原合成一段處理

下面是在以系統管理員身分開啟的 Windows PowerShell 5.1 中整段執行的例子。它只針對本來就在執行的 SysMain，在停止後的 90 秒內到另一個視窗去試同樣的作業。啟動類型不做更改。

# 在系統管理員的 Windows PowerShell 5.1 中整段執行。
$service = Get-Service -Name SysMain -ErrorAction Stop
if ($service.Status -ne 'Running') {
    throw 'SysMain 並未執行。將不更改目前設定並結束。'
}

try {
    Stop-Service -Name SysMain -ErrorAction Stop
    $service.WaitForStatus('Stopped', [TimeSpan]::FromSeconds(30))
    Write-Host '請在 90 秒內到另一個視窗比較同樣的操作。'
    Start-Sleep -Seconds 90
}
finally {
    Start-Service -Name SysMain -ErrorAction Stop
    $service.WaitForStatus('Running', [TimeSpan]::FromSeconds(30))
    Get-Service -Name SysMain | Select-Object Name, Status
}

finally 的作用是在正常結束或發生例外時嘗試復原。它並不能保證在強制關閉 PowerShell 視窗、結束處理程序或斷電的情況下也能復原。 如果中途被打斷，請用 services.msc 確認狀態；若照本步驟停止的 SysMain 仍處於停止狀態，請把它啟動起來。復原失敗時也不要放著不管，請與系統管理員討論。⁹

flowchart TB
    accTitle: 結束暫時停止試驗時的確認
    accDescr: 正常情況下由 finally 嘗試重新啟動，強制結束或復原失敗後要在服務畫面確認狀態。
    A["結束比較"] --> B{"能確認已重新啟動嗎"}
    B -->|"是"| C["在原本狀態下再比較一次"]
    B -->|"否"| D["在服務畫面確認"]
    D --> E["啟動服務或與系統管理員討論"]

圖 6: 就算有自動復原的程式碼，也不要省略最後的狀態確認。

6. Windows Search：停掉之前先想清楚「你想搜什麼」

Windows Search 的索引，是為了快速找到檔案名稱與內容等資訊而建立的機制。索引在建立、更新期間會產生工作量，但這也是讓搜尋變快的準備。²

在 Windows 11 中打開「設定」→「隱私權與安全性」→「搜尋 Windows」，確認索引的進度與搜尋範圍。如果顯示名稱不同，請在設定裡搜尋「索引」。如果有大量用不到的檔案被納入範圍，可以透過「排除的資料夾」或「索引選項」中的「修改」來縮小範圍。¹⁰

例如開發用電腦上的 node_modules 與建置輸出，如果不需要用 Windows 的搜尋來找，就是可以檢視的對象。但這並不是只憑資料夾名稱就一律排除的建議。要先想清楚：把某個位置排除在搜尋之外以後，那裡的內容不能像以前一樣被搜到，你會不會困擾。 只要記錄下更改前的範圍，一旦搜尋出問題就能還原。

這裡說的「排除在搜尋範圍之外」，和後面提到的「排除在 Defender 的保護範圍之外」是兩回事。不要把兩邊的設定一起改。¹¹³

flowchart TB
    accTitle: 縮小搜尋範圍的判斷
    accDescr: 確認被索引的資料夾，再依據是否需要用 Windows 搜尋該位置來檢視範圍。
    A["確認被索引的位置"] --> B{"是搜尋時需要的位置嗎"}
    B -->|"需要"| C["維持在範圍內"]
    B -->|"不需要"| D["記錄後檢視搜尋範圍"]
    D --> E["確認負擔與搜尋結果"]

圖 7: 在停用整個搜尋功能之前，先想想能不能減少要準備的資訊量。

不要把重建當成「先按了再說的修復按鈕」

重建索引是把索引重做一遍的操作。如果它本來就在建立中，那就等於把這份工作再來一次。Microsoft 的說明中提到重建預計最多需要 24 小時左右，而在建立期間搜尋結果可能不完整。¹⁰

因此，不建議只因為磁碟很忙就反覆重建。請先確認進度與錯誤，在調整範圍之後或搜尋結果出問題等確實需要重建的場合再執行。真要執行，就接上電源、留出足以完成的時間，並把重建期間的負擔與穩定狀態下的負擔分開來看。

flowchart TB
    accTitle: 把索引重建期間與完成之後分開看
    accDescr: 重建期間存在重做的負擔與暫時不完整的搜尋結果，效果要在完成之後判斷。
    A["確認必要性後重建"] --> B["重新建立索引的期間"]
    B --> C["等待完成"]
    C --> D["確認搜尋結果與負擔"]

圖 8: 不要只憑剛開始重建時的忙碌程度，就判斷對策成功與否。

7. Defender：不關掉保護，去查「它在檢查什麼」

即使 Antimalware Service Executable 或 MsMpEng.exe 很顯眼，也不建議把關閉即時保護當成日常的加速手段。保護被停用期間，開啟的檔案與下載的檔案都無法照常接受檢查。就算磁碟的數字下降了，如果失去了必要的功能，也不能說是在相同條件下變快了。³

可以用來調查的，是 Microsoft Defender Antivirus 的效能分析器。它會記錄掃描過程，把檢查耗時較長的檔案與相關處理程序整理成報告。它不是用來測量整台電腦所有磁碟延遲的工具，而是與資源監視器中看到的緩慢時段搭配，用來查明 Defender 的檢查是否有關。⁶

flowchart TB
    accTitle: 在維持保護的前提下調查 Defender 的負擔
    accDescr: 維持即時保護的同時記錄緩慢的操作，把掃描報告與操作時間相互對照。
    A["維持即時保護"] --> B["記錄緩慢的操作"]
    B --> C["檢查耗時的報告"]
    C --> D["與實際的等待時間對照"]
    D --> E["也去查檔案產生等因素"]

圖 9: 不是靠關掉安全性功能把數字壓下去，而是去看負擔的內容。

給系統管理員：採集記錄並查看排在前面的項目

官方的前提是 Windows 10 以上、Defender 平台 4.18.2108.X 以上，並且需要系統管理員權限。如果正在使用別的安全性產品，或組織的管理原則限制了相關功能，就不要硬套這套步驟，請向系統管理員或產品窗口確認。¹²

下面在以系統管理員身分開啟的 Windows PowerShell 5.1 中執行。開始記錄後，到另一個視窗重現有問題的操作，再依記錄端的提示用 Enter 結束。如果是日常性的問題，就把重現區間壓短，不要長時間一直記錄。⁶

# 在系統管理員的 Windows PowerShell 5.1 中執行。
Get-Command New-MpPerformanceRecording, Get-MpPerformanceReport -ErrorAction Stop |
    Select-Object Name, Source

# 使用唯一的名稱，以免覆蓋既有的記錄。
$trace = Join-Path $env:TEMP ('Defender-' + [guid]::NewGuid().ToString('N') + '.etl')
Write-Host "記錄到: $trace"
New-MpPerformanceRecording -RecordTo $trace -ErrorAction Stop

# 結束記錄之後再讀報告。
Get-MpPerformanceReport -Path $trace -TopFiles 10 -TopProcesses 10 -ErrorAction Stop

這裡排在前面的，是在記錄區間內對掃描影響最大的項目。它並不表示「把前 10 項排除掉就能安全地變快」。Microsoft 也沒有把這個分析器定位成建議排除項目的工具。¹²

首先要查的是：是什麼在反覆重新產生這個檔案、同樣的作業有沒有重複、能不能在應用程式那側做調整。如果確實需要排除，那要由理解影響範圍與保護削弱程度的系統管理員逐項判斷。不要只憑本文的步驟就把整個 C: 或整個使用者設定檔排除掉。記錄中含有檔案路徑與處理程序資訊，交給外部之前請確認機密資訊的處理方式。

flowchart TB
    accTitle: 從分析報告出發的調查順序
    accDescr: 掃描負擔的前段項目只是調查的入口，要先確認產生來源與頻率再考慮對策。
    A["報告中排在前面的項目"] --> B["確認產生來源與頻率"]
    B --> C["考慮在應用程式那側改善"]
    C --> D["必要時與系統管理員逐項判斷"]
    A -.-> E["不要直接做成排除清單"]

圖 10: 報告是查原因的材料，不是可以放棄保護的檔案清單。

8. 除了這三者也要看：記憶體與儲存裝置的狀態

如果是開了很多應用程式時才變慢，那就同時確認工作管理員裡的記憶體。把不在記憶體中的分頁從儲存裝置讀回來的「硬錯誤」可能會增加，但這並不表示磁碟發生了實體故障。讀回的來源不只是分頁檔，也可能是執行檔或記憶體對應檔。光是出現了數值，也不能斷定就是記憶體不足。¹³

「關掉不需要的應用程式之後，磁碟的等待與操作是否一起改善」值得比較。另一方面，不建議用停用分頁檔的方式來消除讀寫。那會降低可認可記憶體的上限，可能招致別的失敗或不穩定。¹⁴

flowchart TB
    accTitle: 硬錯誤的讀法
    accDescr: 硬錯誤是把不在記憶體中的分頁從磁碟讀回的處理，不是斷定實體故障或記憶體不足的指標。
    A["需要的分頁不在記憶體中"] --> B["從檔案讀回"]
    B --> C["產生磁碟 I/O"]
    C --> D["比較記憶體使用量與操作"]
    B -.-> E["並不表示實體故障"]

圖 11: 不要只憑「硬錯誤」這個名字，就認定是故障或分頁檔的問題。

另外，如果出現讀寫錯誤、儲存裝置的嚴重警告或突然中斷，那麼比起調整服務，更應優先備份重要資料。關於 Windows 的儲存裝置警告，Microsoft 同樣是先引導使用者備份。而且沒看到警告，並不等於所有磁碟都保證正常。¹⁵

備份之後，再確認電腦或儲存裝置廠商提供的診斷工具，以及適合該機型的驅動程式與韌體資訊。不要把舊文章裡那種整批修改登錄檔的做法，在沒核對機型與適用條件的情況下就拿來先試。例如 Microsoft 關於 SysMain 的已知問題中，也有僅限於 Windows 7 特定條件的內容。只憑資料的更新日期，無法判斷它能套用到現在的 Windows 11。¹⁶

flowchart TB
    accTitle: 出現儲存裝置警告時的優先順序
    accDescr: 出現嚴重警告或讀寫錯誤時，優先備份並做符合機型的診斷，而不是最佳化設定。
    A["警告或讀寫錯誤"] --> B["備份重要資料"]
    B --> C["確認廠商的診斷"]
    C --> D["看適用條件再維修或處理"]

圖 12: 出現故障徵兆時，保住資料比把百分比壓下來更優先。

9. 「修好了」不看百分比，要用原本的工作來判定

對策成功與否，要用最初困擾你的那個操作來確認。把「打開應用程式不再等待」「複製能正常完成」「打字不再卡住」這些結果和更改前對比。就算磁碟 100% 的時間變短了，如果搜尋結果不再更新、保護一直停著，也不算完成。

比較時要統一同樣的操作、同樣的儲存位置，以及盡量相同的背景狀態。像 SysMain 這種暫時比較，照「原本狀態→停止期間→原本狀態」的順序確認，比較容易察覺「只是因為時間過去了工作才做完」的可能。不過第二次會有快取生效之類的差別，所以不要把一次比較當成證明了因果關係。

這是本文提出的調查思路。與其蒐集一堆能把數字壓下去的設定，不如記錄哪一項更動在保住必要功能的前提下改善了原本的操作，這在問題再度發生時也更有用。

flowchart TB
    accTitle: 對策完成的判斷
    accDescr: 除了原本的操作有所改善，還要確認搜尋、保護與服務的狀態，才算對策完成。
    A["重新執行原本的操作"] --> B["等待時間是否改善"]
    B --> C["搜尋與保護是否保住"]
    C --> D["暫時的更動是否已還原"]
    D --> E["記錄條件與結果後完成"]

圖 13: 判定的依據不是磁碟的數字，而是必要的工作與功能是否一併恢復。

總結

面對磁碟 100%，並沒有把 SysMain、Windows Search、Defender 一起停掉的萬用步驟。首先確認時段、目標磁碟、檔案與回應時間。在此之上，SysMain 只在必要時做暫時比較，Search 檢視搜尋範圍，Defender 維持保護並做分析——這樣的分工才是出發點。

如果商用 Windows 應用程式持續出現「只有某個操作慢」「只有現場的電腦會當掉」這類問題，也可以透過小村軟體的技術諮詢來討論。有了發生時刻、重現操作、涉及檔案的類型，以及更改前後的記錄，調查的切入點就能具體起來。分享記錄檔或記錄時，請確認其中不含機密資訊。

參考連結

Microsoft Learn, Guidance on configuring system services。關於 SysMain 的職責與停用服務的注意事項。適用對象是 Windows IoT Enterprise。 ↩ ↩²
Microsoft Support, Search indexing in Windows。關於搜尋索引的目的與運作。 ↩ ↩² ↩³
Microsoft Support, Stay protected with the Windows Security app。關於停用即時保護後的影響。 ↩ ↩² ↩³
Microsoft Learn, Troubleshoot performance problems in Windows。關於查看 I/O 回應時間與 System 處理程序的思路。本文沒有把這份面向 Windows Server 的資料中的數值標準，當成所有用戶端電腦的合格線。 ↩ ↩²
Microsoft Virtualization Team, Hyper-V Replica debugging: Why are very large log files generated?。用資源監視器把處理程序與磁碟上的檔案關聯起來的調查實例。 ↩
Microsoft Learn, Performance analyzer for Microsoft Defender Antivirus。關於掃描的記錄與分析步驟。 ↩ ↩² ↩³
Microsoft Learn, Stop-Service。停止服務的命令。 ↩
Microsoft Learn, Start-Service。啟動服務的命令。 ↩
Microsoft Learn, about_Try_Catch_Finally。把收尾處理放進 finally 的語法。 ↩
Microsoft Learn, Troubleshoot Windows Search performance。關於搜尋範圍的調整、重建與進度的查看方式。 ↩ ↩²
Microsoft Support, Windows Search and privacy。關於 Windows Search 的設定與搜尋範圍。 ↩
Microsoft Learn, Microsoft Defender Antivirus Performance Analyzer reference。關於支援條件、系統管理員權限、記錄與報告命令的規格，以及對排除設定的提醒。 ↩ ↩²
Microsoft Learn, How to determine the appropriate page file size for 64-bit versions of Windows。關於硬分頁錯誤與讀回來源的說明。 ↩
Microsoft Learn, Introduction to the page file。關於分頁檔與認可上限的關係。 ↩
Microsoft Support, What to do about a critical warning for a storage device。關於出現嚴重警告時的備份指引。 ↩
Microsoft Learn, Superfetch Sysmain service causes CPU usage spikes。這是以 Windows 7 特定條件為對象的已知問題，本文不把它當成 Windows 11 的通用對策。 ↩

共用相同標籤的最新文章。能以相近的主題延伸理解。

常見問題

整理諮詢這個主題時常見的問題。

磁碟使用率都 100% 了，為什麼只有幾 MB/s？: 因為磁碟處於使用中的時間，和每秒能傳輸的位元組數是兩種不同的指標。細碎的讀寫與 I/O 的等待時間，會讓傳輸量不大卻依然很忙。請確認目標磁碟的回應時間，以及緩慢的操作是否同時發生。
停用 SysMain 一定會變快嗎？: 不能說一定會變快。請先維持一般設定，只有在懷疑與 SysMain 有關時，才在記錄下原本狀態之後，比較暫時停止與重新啟動的差別。是否永久停用，不要只憑這一次比較就決定。
Windows Search 可以停掉嗎？: 它會影響仰賴搜尋索引的搜尋速度與結果的更新，所以不要把它當成第一個對策。請先確認索引的進度；如果有不需要的資料夾被納入搜尋範圍，應優先考慮檢視這個範圍。
可以關掉 Defender 來降低磁碟使用率嗎？: 不建議把關閉即時保護當成日常的加速手段。請用 Microsoft Defender Antivirus 的效能分析器記錄掃描的負擔，查明與哪些檔案或處理有關。報告中排在前面的項目，也不能就這樣加入排除設定。

作者檔案

本文作者的個人檔案頁面。

Go Komura

小村軟體有限公司代表

以 Windows 軟體開發、技術諮詢與故障調查為中心，在難以重現的故障調查與既有資產仍在運作的專案上具有優勢。

查看檔案聯絡我們

公開連結

ORCID GitHub LinkedIn X COM_BLAS COM_BigDecimal

回到部落格一覽

磁碟使用率 100% 要停掉什麼才會好？──分辨 SysMain、Windows Search 與 Defender

1. 先講結論：不要把三者一視同仁地停掉

2. 100% 既不是「容量已滿」，也不是「達到最高速度」

3. 最初的觀察：什麼時候、在哪個檔案上變慢

4. 看到了名字，和它就是根本原因，是兩回事

5. SysMain：先維持原樣，只在有懷疑時做暫時比較

給系統管理員：把 90 秒比較與復原合成一段處理

6. Windows Search：停掉之前先想清楚「你想搜什麼」

不要把重建當成「先按了再說的修復按鈕」

7. Defender：不關掉保護，去查「它在檢查什麼」

給系統管理員：採集記錄並查看排在前面的項目

8. 除了這三者也要看：記憶體與儲存裝置的狀態

9. 「修好了」不看百分比，要用原本的工作來判定

總結

參考連結

同樣是 1GB，為什麼複製照片資料夾比複製一部影片還慢？

Windows 的「硬體加速 GPU 排程」是什麼？打開就會變快嗎？

Windows 名稱解析的順序 ── hosts、DNS 快取、LLMNR/mDNS 與 DoH

關掉記憶體完整性(HVCI)會變快嗎 ── 意義、步驟與判斷

為什麼「剩餘1秒」遲遲不結束？── 進度列與剩餘時間的運作原理

相關主題

Windows 技術主題

常見問題

作者檔案

Go Komura

1. 先講結論：不要把三者一視同仁地停掉

2. 100% 既不是「容量已滿」，也不是「達到最高速度」

3. 最初的觀察：什麼時候、在哪個檔案上變慢

4. 看到了名字，和它就是根本原因，是兩回事

5. SysMain：先維持原樣，只在有懷疑時做暫時比較

給系統管理員：把 90 秒比較與復原合成一段處理

6. Windows Search：停掉之前先想清楚「你想搜什麼」

不要把重建當成「先按了再說的修復按鈕」

7. Defender：不關掉保護，去查「它在檢查什麼」

給系統管理員：採集記錄並查看排在前面的項目

8. 除了這三者也要看：記憶體與儲存裝置的狀態

9. 「修好了」不看百分比，要用原本的工作來判定

總結

參考連結

相關文章

同樣是 1GB，為什麼複製照片資料夾比複製一部影片還慢？

Windows 的「硬體加速 GPU 排程」是什麼？打開就會變快嗎？

Windows 名稱解析的順序 ── hosts、DNS 快取、LLMNR/mDNS 與 DoH

關掉記憶體完整性(HVCI)會變快嗎 ── 意義、步驟與判斷

為什麼「剩餘1秒」遲遲不結束？── 進度列與剩餘時間的運作原理

相關主題

Windows 技術主題

常見問題

作者檔案

Go Komura