收缩数据库后Elastic Pool存储利用率占比未下降，咨询其指标原理

核心计算逻辑 #

弹性池的存储利用率是池内所有数据库的已分配空间总和除以池的总存储容量，这里必须明确两个关键空间概念：

• 实际使用空间：数据库中真实存储的数据、索引、日志等占用的实际空间，常规收缩操作释放的是这部分里的内部空闲碎片。
• 已分配空间：Azure SQL为每个数据库预分配的存储块，这部分是数据库占用的池级资源，即使删除数据或做内部空间整理，已分配空间不会自动返还给弹性池。

为什么收缩后利用率没下降？ #

• 普通的DBCC SHRINKDATABASE仅做数据库内部空闲空间的整理，把碎片移到数据文件末尾，但不会将空间返还给弹性池（即不会减少数据库的已分配空间）。只有执行DBCC SHRINKFILE并指定合理的目标大小，且文件末尾有足够空闲空间时，才会让数据库释放已分配的空间回池。
• 弹性池内每个数据库有最大数据大小限制，如果收缩后数据库的已分配空间仍低于这个阈值，池的总已分配空间不会变化，利用率自然不会下降。
• Azure SQL的存储指标存在15-30分钟的更新延迟，刚完成操作就查看可能看不到实时变化。

如何真正释放空间给弹性池 #

如果确实需要降低池的存储利用率，需针对目标数据库执行文件级收缩：

USE [目标数据库名];
GO
-- 替换为你的数据文件名和目标大小（单位MB）
DBCC SHRINKFILE (N'DB_Data', 2048); 
GO

注意：频繁收缩会导致索引严重碎片化，大幅影响查询性能，仅在必要时操作，之后建议重建或重组相关索引。

内容的提问来源于stack exchange，提问作者KKR