TRUNCATE PARTITION 不能直接释放磁盘空间，仅标记数据页为可复用；真正释放需 DISCARD + DROP + REORGANIZE 或 EXCHANGE PARTITION + TRUNCATE 归档表。
TRUNCATE PARTITION 语法是否真能释放磁盘空间
不能直接释放。MySQL 的 TRUNCATE PARTITION 只清空分区数据并重置自增计数器，但底层物理文件（如 #P#p202301.ibd）仍保留在磁盘上，大小不变——它只是把数据页标记为“可复用”，不归还给文件系统。
真正释放磁盘空间必须执行 DISCARD + IMPORT 或 DROP + RECREATE
想让磁盘空间实际回落，得让 MySQL 删除并重建分区文件。最稳妥的做法是先 DISCARD TABLESPACE，再 DROP PARTITION，最后用 REORGANIZE PARTITION 或重建表补全结构。但注意：该操作要求表使用 innodb_file_per_table=ON（默认开启），且分区必须是独立表空间（即每个分区对应一个 .ibd 文件）。
-
ALTER TABLE orders DISCARD PARTITION p202201 TABLESPACE;→ 卸载分区表空间，.ibd 文件被移走（但未删） -
ALTER TABLE orders DROP PARTITION p202201;→ 彻底删除分区定义和残留元数据 -
ALTER TABLE orders REORGANIZE PARTITION p202202 INTO (PARTITION p202201 VALUES LESS THAN (202202), PARTITION p202202 VALUES LESS THAN (202203));→ 拆出新分区占位（可选，用于维持分区数量）
执行后检查 ls -lh /var/lib/mysql/dbname/，确认 orders#P#p202201.ibd 已消失，磁盘 df -h 显示空间回升。
为什么不能只用 DROP PARTITION？
DROP PARTITION 本身会删除数据+元数据+物理文件，看似一步到位——但它有硬性限制：只能用于 RANGE/LIST 分区，且不能是最后一个分区（否则报错 ERROR 1507 (HY000): Cannot remove all partitions, use DROP TABLE instead）。更关键的是，如果表启用了 innodb_file_per_table=OFF，所有分区共用 ibdata1，DROP PARTITION 根本不会释放磁盘空间。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 检查方式：
SELECT @@innodb_file_per_table;必须返回1 - 查看分区文件：进入数据目录，确认存在形如
tablename#P#partitionname.ibd的独立文件 - 误操作风险：
DROP PARTITION不可回滚，且会阻塞 DML，建议在低峰期加LOCK=SHARED执行
归档场景下更安全的替代方案：EXCHANGE PARTITION + TRUNCATE
如果目标只是快速清空旧分区并腾出空间，又不想破坏主表结构或承担 DROP 风险，推荐用交换分区法。先创建一个空的、同结构的归档表，再用 EXCHANGE PARTITION 把旧分区数据“换”出去，最后对归档表执行 TRUNCATE 或 DROP。
CREATE TABLE orders_archive LIKE orders; ALTER TABLE orders EXCHANGE PARTITION p202201 WITH TABLE orders_archive; TRUNCATE TABLE orders_archive;
这个流程中，EXCHANGE 是原子操作、毫秒级完成，不拷贝数据；后续 TRUNCATE 归档表才会真正删掉 .ibd 文件（前提是 innodb_file_per_table=ON）。比直接操作原表分区更可控，也便于后续审计或延迟删除。
真正容易被忽略的是：分区交换要求两个表的行格式、压缩属性、索引完全一致，连 ROW_FORMAT=DYNAMIC 这种细节不匹配都会报错 ERROR 1731 (HY000): Operation not allowed on a table with partitions。动手前务必用 SHOW CREATE TABLE 对比两表建表语句。
