DELETE后磁盘空间不释放是正常行为，因InnoDB和SQL Server仅做逻辑删除标记而不归还物理空间；真正收缩需满足innodb_file_per_table=ON、无长事务等条件，并通过OPTIMIZE TABLE或重建索引实现。
DELETE后空间不释放是正常行为，不是SQL写错了
执行DELETE后磁盘空间没变小，不是语句有问题，也不是数据库坏了——InnoDB 和 SQL Server 都只做逻辑标记：InnoDB 把行头的delete_mask设为 1，SQL Server 在页内打“已删除”标记。数据页仍属于.ibd或.mdf文件，操作系统根本看不到“空”。SHOW TABLE STATUS的Data_length、sys.dm_db_file_space_usage的unallocated_extent_page_count都不会下降。
MySQL：OPTIMIZE TABLE不是万能钥匙，得看条件
OPTIMIZE TABLE t或ALTER TABLE t ENGINE=InnoDB本质是重建表，但只在满足以下条件时才真正缩文件：
-
innodb_file_per_table = ON（5.6.6+ 默认开启，但老实例常被手动关掉；若为OFF，空间永远留在ibdata1里） - 没有长事务阻塞：查
SELECT * FROM information_schema.INNODB_TRX WHERE TIME_TO_SEC(NOW() - trx_started) > 600，有结果必须先KILL - RDS/PolarDB 等托管服务常禁用该命令，或自动转到只读副本执行——得先翻控制台文档确认是否允许
注意：OPTIMIZE TABLE在 MySQL 5.7+ 等价于ALTER TABLE t FORCE，仍需两次元数据锁，大表可能锁表数小时。
SQL Server：别直接DBCC SHRINKDATABASE，优先重建索引
DBCC SHRINKDATABASE能回收空间，但会把聚集索引碎片率拉高到 60% 以上，后续查询性能断崖下跌。更稳妥的做法是：
- 堆表（无聚集索引）且全删了：加
TABLOCK后重建ALTER TABLE dbo.LogTable REBUILD WITH (DATA_COMPRESSION = PAGE) - 聚集表：用
ALTER INDEX ALL ON dbo.Orders REBUILD，它整理页、合并空洞、更新统计信息 - 真要收缩文件：只对目标数据文件操作，例如
DBCC SHRINKFILE('MyDB_Data', 10240)（目标 10GB），而非整个库 - 收缩后必须立刻跟
ALTER INDEX ... REBUILD，否则碎片白清
TRUNCATE和DROP能立刻释放，但代价明确
TRUNCATE TABLE和DROP TABLE确实秒级释放空间，但它们不是DELETE的替代品：
-
TRUNCATE不支持WHERE条件，会重置自增列，且无法触发DELETE触发器 -
DROP破坏外键依赖，要求重建表结构和权限，生产环境风险极高 - 启用
READ_COMMITTED_SNAPSHOT（SQL Server）或存在活跃 MVCC 事务（MySQL）时，TRUNCATE也可能被阻塞
真正需要的是判断：你到底要“内部复用空页”，还是“把文件切小还给操作系统”——前者靠后续INSERT自然完成，后者才值得动重建或收缩。
