MS SQL：在 TRUNCATE / DROP 後修整 SSD？
我考慮為我們的新 Microsoft SQL Server 使用其中一種新奇的純 SSD SAN 系統。“花哨”的意思是，它支持/使用諸如塊壓縮/重複數據刪除/0x00辨識/磁碟空間過度供應等的東西。
當我刪除或截斷表時，SQL 伺服器通常只會將頁面分配映射中的頁面標記為空閒，但不會觸及頁面本身中的數據（例如用 0x00 覆蓋它）。這對於 HDD 來說非常好（因為速度很快），但 SSD 會預先知道一個塊是否空閒並且可以被其內部常式覆蓋，或者數據是否仍然重要並且需要保留。
所以我的問題是：Microsoft SQL Server 是否支持 SSD-Trim-Command 以某種方式釋放空間？當然，無需縮小文件或執行其他手動/緩慢的操作，這些操作會分散我的索引、阻止我的查詢等。
或者有沒有辦法強制 SQL 伺服器用 0x00 覆蓋未分配的數據（這將被 SAN 辨識，因此它釋放內部空間），即使與 SSD-TRIM 相比這是更糟糕的選擇？
PS：我知道在數據庫文件中有一些（！）未分配的空間用於新數據通常是有意義的，但只是假設我刪除的內容比我在接下來的 6 個月中添加的要多，或者我使用分區和被刪除的東西在目前熱數據之外的其他文件中抵抗（但舊文件組仍然不是空的，所以它不能被刪除/收縮）。
Microsoft SQL Server 是否支持 SSD-Trim-Command 以某種方式釋放空間？
這實際上不在數據庫的範圍內，數據庫是作業系統之上的應用程序。Windows 以最常見的形式支持 TRIM，即通過 SQL Server 位於其之上的 NTFS（作為最常見的文件系統）（技術上還有 RAW 和 ReFS），這是造成這種行為的主要原因，除了一些後台 Windows 程序和服務，例如儲存優化。
這裡最大的問題是這不是 SQL Server 使用儲存的方式。例如，當表被截斷時，根據大小，它可能在同一命令中被釋放，或者它可能被標記為作為後台清理的一部分釋放。無論哪種方式，該空間都將在 SQL Server 內部標記為可用，這意味著就 NTFS/ReFS 而言，集群仍在使用中。如果 SQL Server 將頁面清零，它仍然會跨越 1 個或多個不會在底層文件系統中被標記為空閒的集群，同樣沒有真正的 TRIM。SQL Server 將重新使用該空間，因此它不會失去，並且不會在文件系統和磁碟級別分配命中，因為它已經分配了。
總而言之，如果模型在釋放頁面時在文件系統級別釋放（也取決於集群大小），這將導致更多的磁碟磨損和 IO，以及文件系統碎片（可能/將導致可怕的NTFS 作業系統錯誤 665）。
編輯：這是一個非常高的級別，不涉及內部頁面大小、磨損均衡以及 SSD 和 NVMe 的寫入放大部分。
TRIM 通常由作業系統中的文件系統層發布。縮小表空間文件並將該空間返回給作業系統的函式將導致為這些塊發出 TRIM。
花時間歸零塊將消耗不必要的 I/O 並降低性能。
除非您的數據庫完全是靜態的，否則數據庫將再次增長並很快再次弄髒這些塊，因此以這種方式對空間進行微觀管理並沒有太大的好處。供企業使用的現代 SSD 在預清理頁面方面非常聰明。