為什麼 SELECT 仍在使用 CPU 和 DiskIO？
我有一個大數據庫，大約 30GB。為了從表中刪除一些數據（大多數數據都在這個表中，僅僅是因為行數），我必須批量刪除。但是，如果我批量刪除太多，系統就會變得很慢。所以，我們要做的是：查詢將要刪除的數據#，然後使用#的1/10作為批量大小。
當我測試這個時，我發現了一個奇怪的事情。
由於要刪除大量數據，因此刪除批處理循環需要很長時間才能完成。在刪除過程中，當我使用 sp_who2 檢查時，我可以看到 2 個 SPID 的 CPU 時間和 DiskIO 不斷變化。一個用於 DELETE，一個用於 SELECT。刪除是為了刪除。但 SELECT 用於獲取將被刪除的數據的數量。
我在 c# 中使用 sqlcommand 來執行此操作。SELECT 是先完成的，一旦得到 #，然後我們執行 DELETE。日誌實際上顯示了 SELECT 的結果。我的問題是：為什麼 sp_who2 仍然顯示 CPU 時間和 DiskIO 變化？應該已經完成了嗎？什麼會導致這個？
同時，刪除的 CPU Time 和 DiskIO 也在發生變化。
有人對此有解釋嗎？
謝謝
如果 DELETE 語句中有 where 子句，則伺服器仍需要在 DELETE 語句內部執行 SELECT 以便僅刪除指定的記錄。
您可能只發出一個 DELETE 語句，但這是 SQL 的一種便利。數據庫軟體必須處理該語句並執行必要的邏輯來完成這項工作。這是它所做的事情之一，你通常不會想到，直到你碰巧注意到它，就像你現在所做的那樣。
我建議不要刪除行，而是創建一個新表，其中包含您想要保留在表中的數據。創建適當的約束和索引。
然後刪除原始表，然後重命名新表。如果您要刪除大量數據，這將是最好的。
當您只刪除與總數據相比非常少的數據時，刪除批次是好的。
另外，為什麼需要選擇？為什麼不使用表 where 的刪除頂部（5000）？
此外，我相信這或多或少是一種維護類型的任務，為什麼不創建用 TSQL 編寫的計劃作業而不是使用 C# 程式碼。