我们在 Azure SQL 数据库中有一个表，该表曾经有一个存储 pdf 文件的 nvarchar(max) 列。（外部开发人员的奇迹。）表增长到 156 GB。它有 476000 行。更改逻辑后，我们不再需要 pdf 列。删除其中数据的唯一合理方法是删除该列并重新创建该列（以防某些奇怪的进程仍在引用它）。
但是，表大小仍报告为 156 GB。我刚刚创建的备份表 (SELECT INTO) 是 128 MB，因此这似乎是数据的实际大小。
我让索引重建（在线）在聚集 PK 索引上运行过夜。它在 8 到 12 小时之间的某个时间因 TCP 错误而失败。该索引仍存在 95% 的碎片，报告的大小仍为 156 GB。
有没有解释为什么这么慢？有没有更好的办法？生产数据库、表由网站使用，必须可访问，因此不能离线执行，除非需要不到 10 分钟 - 没有人可以保证。
我可以在备份表上建立所有索引，删除原始表并重命名备份吗？这听起来很冒险（丢失在错误时间创建的记录的风险很小）。
我正在努力让 Azure 意识到它不再被使用。已分配，我对此表示同意。用过，没那么多：
有问题的表：
同样，问题不是保留空间，而是已使用空间。