直接DELETE清空分区表历史分区效率低且风险高，因分区清空本质是卸载数据单元而非删数据，若分区定义与物理存储解耦不清，易将高效操作变为高危操作。
为什么不能直接用 DELETE 清空分区表的历史分区
直接对分区表执行 DELETE FROM table_name WHERE partition_col 看似简单，但实际会触发全表扫描+逐行删除，不仅锁表时间长、生成大量 undo/redo 日志，还可能拖垮线上查询。尤其当历史分区占表体积 80% 以上时，<code>DELETE 几乎不可控。
真正高效的方式是「删分区」而非「删数据」——前提是表确实按分区键（如日期、ID 范围）做了物理分区，且引擎支持（MySQL 5.7+ / 8.0、PostgreSQL 10+、Oracle、TiDB 等主流系统均支持）。
MySQL 中用 DROP PARTITION 快速清理历史分区
MySQL 的 ALTER TABLE ... DROP PARTITION 是 DDL 操作，本质是移除分区定义 + 删除底层文件，毫秒级完成，不走事务日志，也不锁全表（仅锁对应分区元数据）。
- 先查清当前分区结构：
SELECT PARTITION_NAME, PARTITION_DESCRIPTION FROM INFORMATION_SCHEMA.PARTITIONS WHERE TABLE_NAME = 'your_table' AND TABLE_SCHEMA = 'your_db'; - 确认要删的分区名（如
p202201,p202202），再执行：ALTER TABLE your_table DROP PARTITION p202201, p202202; - 注意：若使用
RANGE COLUMNS或LIST COLUMNS，分区名是自动生成的（如p0,p1），需结合PARTITION_DESCRIPTION判断边界值 - 不能删掉最后一个分区（MySQL 报错
ERROR 1507 (HY000): Cannot remove all partitions, use DROP TABLE instead），至少保留一个
PostgreSQL 中用 TRUNCATE 分区表继承子表
PostgreSQL 原生分区（v10+）底层是基于表继承实现的，每个分区都是独立子表。因此最高效方式是直接 TRUNCATE 对应子表，而非父表。
- 查子表名：
SELECT inhrelid::regclass FROM pg_inherits WHERE inhparent = 'parent_table'::regclass; - 确认历史分区子表（如
sales_2022_q1），执行：TRUNCATE TABLE sales_2022_q1; - 比
DROP TABLE更安全：不破坏父表结构和约束，也不影响后续插入路由 - 如果用了
ATTACH PARTITION方式创建的声明式分区，子表名默认为parent_table_pN格式，可用\d+ parent_table在 psql 中快速查看
清空前必须检查的三个关键点
跳过这三步，极大概率导致误删或操作失败：
-
确认分区策略是否生效：执行
EXPLAIN SELECT * FROM table WHERE partition_col = '2022-01-01'，看是否只扫描目标分区（partitions: p202201）。若显示partitions: all，说明分区未被识别，可能是字段类型不匹配（如DATEvsSTRING）、函数包装（TO_DAYS(col)）或 MySQL 版本太低 -
检查是否有外键或物化视图依赖该分区：MySQL 不允许对含外键引用的分区执行
DROP PARTITION；PG 中若子表被物化视图或视图引用，TRUNCATE可能失败 -
确认备份与回滚方案：
DROP PARTITION和TRUNCATE均不可回滚（非事务性操作）。生产环境务必提前导出关键分区：mysqldump --where="partition_col backup.sql
分区清空不是“删数据”，而是“卸载数据单元”。一旦分区定义和物理存储解耦不清晰，就容易把高效操作做成高危操作。
