【數據庫】記一次DELETE九千萬條數據的經歷

時間 2019-12-12

原文原文鏈接

週四晚上要把測試數據庫結構備份一份週五到客戶方部署到客戶的測試服務器上。數據庫

以前備份一個庫通常幾分鐘十幾分鍾吧，⏰18點下班的我決定17點停掉測試站點開始備份數據，嘻嘻~服務器

二十分鐘後數據備份完成，看了下文件大小20G，俺擦怎麼拷到客戶機，並且也不該該有這麼大的數據，因而開始下面的表演~測試

1.查看庫中每一個表的數據量

SELECT  a.name AS 表名 ,
        MAX(b.rows) AS 記錄條數
FROM    sys.sysobjects AS a
        INNER JOIN sys.sysindexes AS b ON a.id = b.id
WHERE   ( a.xtype = 'u' )
GROUP BY a.name
ORDER BY 記錄條數 DESC;

發現有張表有九千五百萬數據spa

看看這張表裏都是什麼數據：SELECT TOP 100 * FROM RoomStatus_Dump3d

啊~難受😭 。一個SELECT執行了3分鐘。日誌

檢查發現有2011年的數據，只有6千條2019年的數據是須要的，2019年之前的數據全刪掉吧😡code

使用truncate大概1秒就搞定了，好嗨喲~使用delete，但在刪除時我能夠根據條件時間小於2019年嗎？（上面查詢100條用了三分鐘）blog

因而決定時間倒敘查詢後按月刪吧，刪了幾回後總結出來規律，每刪除1千萬數據（6個月數據量）大概須要十分鐘索引

算了一下：（2019-2011）* 2 * 10=160分鐘；去領個盒飯吧~🍗事務

我以爲可能這張表的索引碎片膨脹了

2.檢查表中的索引碎片

--檢查表的索引碎片狀況
DECLARE @table_id INT;
SET @table_id = OBJECT_ID('RoomStatus_Dump');
--執行
DBCC SHOWCONTIG(@table_id);

解釋以下：

Page Scanned-掃描頁數：

若是你知道行的近似尺寸和表或索引裏的行數，那麼你能夠估計出索引裏的頁數。看看掃描頁數，若是明顯比你估計的頁數要高，說明存在內部碎片。

Extents Scanned-掃描擴展盤區數：

用掃描頁數除以8,四捨五入到下一個最高值。該值應該和DBCC SHOWCONTIG返回的掃描擴展盤區數一致。若是DBCC SHOWCONTIG返回的數高，說明存在外部碎片。碎片的嚴重程度依賴於剛纔顯示的值比估計值高多少。

Extent Switches-擴展盤區開關數：

該數應該等於掃描擴展盤區數減1。高了則說明有外部碎片。

Avg. Pages per Extent-每一個擴展盤區上的平均頁數：

該數是掃描頁數除以掃描擴展盤區數，通常是8。小於8說明有外部碎片。

Scan Density [Best Count:Actual Count]-掃描密度［最佳值:實際值］：

DBCC SHOWCONTIG返回最有用的一個百分比。這是擴展盤區的最佳值和實際值的比率。該百分比應該儘量靠近100％。低了則說明有外部碎片。

Logical Scan Fragmentation-邏輯掃描碎片：

無序頁的百分比。該百分比應該在0％到10％之間，高了則說明有外部碎片。

Extent Scan Fragmentation-擴展盤區掃描碎片：

無序擴展盤區在掃描索引葉級頁中所佔的百分比。該百分比應該是0％，高了則說明有外部碎片。

Avg. Bytes Free per Page-每頁上的平都可用字節數：

所掃描的頁上的平都可用字節數。越高說明有內部碎片，不過在你用這個數字決定是否有內部碎片以前，應該考慮fill factor（填充因子）。

Avg. Page Density (full)-平均頁密度（完整）：

每頁上的平都可用字節數的百分比的相反數。低的百分比說明有內部碎片

3.清除索引碎片

有不少方法，我這裏使用刪除重建索引🤺

--刪除索引
DROP INDEX RoomStatus_Dump.idx_RoomStatus_Dump_hotelid
DROP INDEX RoomStatus_Dump.PK_RoomStatus_Dump

--彙集索引
create CLUSTERED INDEX PK_RoomStatus_Dump ON RoomStatus_Dump(字段, 字段, 字段)
--建立非彙集索引
create NONCLUSTERED INDEX idx_RoomStatus_Dump_hotelid ON  RoomStatus_Dump(字段)