DROP PARTITION 不一定“秒级”是因为其实际执行受长事务MVCC快照、底层文件清理机制（如innodb_file_per_table=OFF）等影响，元数据解绑后物理删除可能阻塞；真正秒级需满足元数据立即生效且不触发物理操作。
为什么直接 DROP PARTITION 不一定“秒级”？
很多用户以为执行 ALTER TABLE ... DROP PARTITION 就是原子操作、必然毫秒完成，实际并非如此。MySQL 8.0+ 和 PostgreSQL（通过 DETACH PARTITION）确实能快速解绑分区元数据，但若该分区仍被事务引用（如长事务持有 MVCC 快照）、或底层文件未真正清理（如 MySQL 的 innodb_file_per_table=OFF），后续 I/O 清理可能阻塞并拖慢响应。真正的“秒级删除”必须确保：元数据变更立即生效 + 物理文件不参与本次操作。
用空表交换实现零影响删除的实操步骤
核心思路是：建一个结构完全一致的空表 → 把目标历史分区“换出去”到这个空表 → 再异步删空表。整个交换过程只改元数据，不移动数据。
- MySQL（5.7+，InnoDB，LIST/RANGE 分区）：
ALTER TABLE target_table EXCHANGE PARTITION p_202201 WITH TABLE empty_stub;，要求empty_stub表结构、索引、字符集、ROW_FORMAT 全部一致，且无数据、无外键、非临时表 - PostgreSQL（10+）：
ALTER TABLE target_table DETACH PARTITION p_202201; ALTER TABLE p_202201 OWNER TO some_role;，然后DROP TABLE p_202201可异步执行；注意 DETACH 后原分区表名变为独立表，需手动清理 - 交换前务必校验：
SELECT PARTITION_NAME, TABLE_ROWS FROM INFORMATION_SCHEMA.PARTITIONS WHERE TABLE_NAME = 'target_table' AND PARTITION_NAME = 'p_202201';确认行数非零，避免误删空分区
容易踩的坑：约束、索引与权限陷阱
交换失败往往不是语法问题，而是隐式约束冲突。
- MySQL 要求空表不能有
FULLTEXT索引，也不能有GENERATED COLUMN（除非目标分区也没有） - PostgreSQL 的 DETACH 要求目标分区无行级安全策略（RLS）、无
BEFORE ROW触发器，否则报错ERROR: cannot detach partition with triggers - 权限上：MySQL 需要
ALTER+CREATE+DROP；PostgreSQL 需要源表和目标表的OWNER或ALTER ANY TABLE，普通TRUNCATE权限不够 - 时间分区场景下，别用
TO_DAYS(NOW()) - 365这类表达式建分区名——交换时无法匹配硬编码的分区名p_202201
交换后物理清理时机与监控建议
交换只是把数据“移出”主表，不代表磁盘立刻释放。MySQL 在 innodb_file_per_table=ON 下，DROP TABLE empty_stub 才真正删.ibd 文件；PostgreSQL 的 DROP TABLE 会触发后台 auto-vacuum 清理，但大表可能持续数分钟。
- 监控真实磁盘释放：MySQL 查
sys.schema_table_statistics中total_logical_reads是否下降；PostgreSQL 查pg_stat_progress_vacuum视图确认是否在清理 - 避免高峰期执行
DROP TABLE：它会获取AccessExclusiveLock，阻塞所有对该表的访问，哪怕只是SELECT - 生产环境建议加超时控制：MySQL 可设
lock_wait_timeout=3；PostgreSQL 可在事务中加SET lock_timeout = '3s';
真正卡住的从来不是交换本身，而是后续那个你以为“随便什么时候都能删”的 DROP TABLE —— 它在大容量场景下既不轻量，也不安静。
