DELETE不会让磁盘文件变小，这是InnoDB等主流数据库的默认行为，仅逻辑标记删除（如设delete_mask位）、不归还物理空间；真正释放需重建表（如ALTER TABLE ENGINE=InnoDB）或专用收缩命令。
DELETE 不会让磁盘文件变小，这是 InnoDB、SQL Server、PostgreSQL 等主流引擎的默认行为，不是你语句写错，也不是数据库坏了。
DELETE 只是逻辑标记，不碰物理文件
DELETE 操作本质是“打标”，不是“擦除”：
- InnoDB 把行头的
delete_mask位设为 1，并把该页加入空闲链表，但整页仍保留在.ibd文件里 - SQL Server 在数据页内打“已删除”标记，页仍归属原文件，操作系统看不到空
- PostgreSQL 标记为
dead tuple，后续需VACUUM清理，但默认不返还 OS - Oracle 将行置为“可重用”，但高水位线（HWM）不动，文件尺寸不变
所以你会看到这些现象：
-
SHOW TABLE STATUS中Data_length几乎不变，Data_free反而升高 -
du -sh table.ibd或sys.dm_db_file_space_usage显示文件大小纹丝不动 - 即使
SELECT COUNT(*) = 0，磁盘使用率也不降
这不是空间泄漏，是为 MVCC、并发写入稳定性和页复用效率做的设计取舍。
MySQL 怎么真正缩小 .ibd 文件
必须重建表，让引擎把有效数据重写进新页，旧页才被丢弃、OS 才能回收：
- 优先用
ALTER TABLE t ENGINE=InnoDB：语义清晰，RDS 多数支持 Online DDL - 次选用
OPTIMIZE TABLE t：MySQL 5.7+ 等价于ALTER TABLE t FORCE，但部分版本锁更重 - 超大表或不能停写：用
pt-online-schema-change --alter "ENGINE=InnoDB" --execute
但必须满足三个硬前提：
-
innodb_file_per_table = ON（否则所有表共用ibdata1，重建无效） - 磁盘剩余空间 ≥ 当前
Data_length × 1.5（临时表 + redo/binlog 要落盘） - 无长事务阻塞 purge：查
information_schema.INNODB_TRX，确认trx_started超 600 秒的连接已结束
另外注意：TRUNCATE TABLE t 能立刻释放空间，但它不支持 WHERE，且重置自增、破坏外键依赖——别当成 DELETE 的替代品乱用。
SQL Server 堆表删完还占空间怎么办
堆表（无聚集索引）最难释放页，尤其启用 READ_COMMITTED_SNAPSHOT 后，TABLOCK 都可能失效：
- 全表清空 → 用
TRUNCATE TABLE t（快、释放页、不走日志） - 条件删除后想释放 → 加
WITH (TABLOCK)提示：但仅对未启用行版本控制的库有效 - 长期反复删 → 直接建聚集索引：
CREATE CLUSTERED INDEX ix_id ON t(id)，后续DELETE自动触发页合并
DBCC SHRINKFILE 是最后手段：它移动页、制造碎片、可能阻塞快照读，且只对目标文件生效——如果大表在非 PRIMARY 文件组，收缩 PRIMARY 完全没用。
真正释放空间的关键不在“删”，而在“重建”或“收缩”。最容易被忽略的是托管服务限制：RDS、PolarDB、Azure SQL 等常禁用 OPTIMIZE TABLE 或自动转到只读副本执行，得先查控制台文档；还有人直接在磁盘使用率 >90% 时跑 ALTER TABLE，结果临时文件写满，卡死在 ERROR 1034。
