Mat*_*les 6 fragmentation azure-sql-database
我有一个在 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 个盘区，然后使用统一盘区。这就是原因，小表中的碎片率很高，但您不应该担心它。
您不应该查看数据库有多大，而应该查看其中有多少是空的。我不确定这对账单有何影响。华泰