Fragmentation
SQL Azure 碎片/數據庫大小
我有一個在 SQL Azure 上執行的數據庫，目前為 280mb。它是我們即將投入生產的系統的測試數據庫，因此數據經常被批量刪除然後重新創建。
當我在 SQL Azure 上使用“複製”功能時，它創建的新數據庫只有 156mb。當執行查詢以顯示每個表正在使用多少數據時，似乎每個表的大小幾乎是以前的一半。
我已經確定這將歸結為數據碎片，但我的問題是我能做些什麼呢？微軟似乎沒有對數據本身進行任何維護，由於它是按使用付費的模型，當我沒有 1gb 的數據時，我最終會達到 1gb 的限制！
作為參考，這是我執行以顯示表大小的查詢：
select sys.objects.name, (reserved_page_count * 8.0 / 1024) from sys.dm_db_partition_stats, sys.objects where sys.dm_db_partition_stats.object_id = sys.objects.object_id
馬修，
我沒有直接使用 SQL Azure 的經驗，但我認為同樣的規則適用於普通 SQL Server 實例。
280 mb 是一個非常非常小的數據庫，碎片成本幾乎為 0。以這個小數據庫的大小，我認為您無法控制，也不應該擔心。
以上是因為 SQL Server 在創建新表時，不知道該表會有多大。數據儲存在 8 kb 的頁面中，一個範圍是 8 個連續頁面的集合。有兩種類型的範圍，混合範圍和統一範圍。統一範圍意味著所有 8 個頁面將被同一個對象（例如 TableA）使用，混合範圍意味著該範圍可以被多達 8 個不同的表使用。由於 SQL Server 不知道表有多大，它會從單頁分配開始，直到表達到 3 個擴展區，然後再使用統一擴展區。這就是原因，小表中的碎片很高，但你不應該擔心它。
與其查看數據庫有多大，不如查看其中有多少是空的。我不確定這會如何影響計費。高溫高壓
還要檢查頁面填充因子。這個百分比決定了在分配新頁面之前應該用數據填充頁面的多少。這是為了減少碎片，但會佔用更多的磁碟空間。