update后空间未释放，是因为它不产生可收缩的空闲页；lob列更新后shrink无效是sql server 2008 r2–2014已知缺陷（kb2967240）；真正释放空间应优先重建索引或表，而非直接shrink。
UPDATE后空间没变，不是 shrink 失败，是它本来就不该动
执行 UPDATE 后用 DBCC SHRINKDATABASE 发现空间没释放，这不是命令没跑通，而是 shrink 根本没东西可收——UPDATE 不产生“可收缩的空闲页”，它只是改数据，页还是满的。除非你把某列从长变短（比如 VARCHAR(2000) 改成 VARCHAR(10)），且原页上腾出了足够连续空间，SQL Server 才可能把行挪走、留出整页空闲；但这种情况极少，更常见的是页内碎片增加、甚至页分裂。
LOB 列更新后 shrink 无效，是已知缺陷，不是操作错
如果你更新的是 TEXT、IMAGE、XML 或大 VARCHAR(MAX)/VARBINARY(MAX) 列，DBCC SHRINKDATABASE 或 DBCC SHRINKFILE 极大概率不释放空间——这是 SQL Server 2008 R2 至 2014 版本中确认存在的 bug（KB2967240）。即使页里实际已无 LOB 数据，内部 LOB 分配结构仍被保留，shrink 看不到“空”。
- 检查是否涉及 LOB：运行
SELECT c.name, t.name FROM sys.columns c JOIN sys.types t ON c.user_type_id = t.user_type_id WHERE c.object_id = OBJECT_ID('YourTable') AND t.name IN ('text','ntext','image','xml','varcharmax','varbinarymax') - 修复方式只有两个：升级到已包含修复的 CU（如 SQL Server 2012 SP2 CU2），或绕过 shrink，用
ALTER TABLE ... REBUILD强制重写整个表（含 LOB 页） - 注意：
REORGANIZE对 LOB 无效，必须用REBUILD
shrink 报“可用空间为 0”，说明文件真没空页了
DBCC SHRINKDATABASE 提示 “file id X does not have enough free space to shrink” 不是报错，是事实陈述：当前数据文件里所有已分配页都还在使用中，sys.dm_db_file_space_usage 的 available_page_count 接近 0。这通常意味着：
- 刚做完大量
UPDATE，没伴随DELETE或TRUNCATE，所以没逻辑空页 - 表是堆（无聚集索引），
UPDATE后行位置不变，旧位置仍占着页 - 自动增长设得过大，文件已分配但未填满，但 shrink 只看“已分配页内的空闲”，不看“未分配区”
- 日志文件卡在
log_reuse_wait_desc = LOG_BACKUP，导致事务日志无法截断，连带阻塞数据文件收缩
想真正回收空间，别只盯 shrink，优先做这几件事
多数人想 shrink 是为了腾磁盘，但真正有效的路径往往不是直接收缩文件，而是先清理内部碎片、再让空间自然“浮上来”：
- 对聚集表：运行
ALTER INDEX ALL ON dbo.YourTable REBUILD—— 它会重新组织页、合并空洞、更新统计信息，比 shrink 更安全，且释放的页能被后续 INSERT 复用 - 对堆表：用
ALTER TABLE dbo.YourTable REBUILD（SQL Server 2008+），等效于加聚集索引再删掉，强制物理重排 - 确认恢复模式和日志备份：如果数据库是完整恢复模式，先做
BACKUP LOG YourDB TO DISK = '...'，否则日志不截断，数据文件 shrink 也会受牵连 - 只收缩单个文件：用
DBCC SHRINKFILE('YourDataFile', target_size)，而不是整个库；收缩后立即查sys.dm_db_index_physical_stats，若碎片 >30%，说明 shrink 已伤性能，得补 rebuild
shrink 是外科手术，不是维生素；它解决的是“磁盘告警且不能扩容”这种硬约束，不是日常维护动作。真正容易被忽略的，是误把 UPDATE 当成 DELETE 来期待空间释放——它们在存储引擎层面的行为完全不同。
