用 DROP PARTITION 替代 DELETE 可高效删除海量分区数据，因其为毫秒级元数据操作，不触发行级删除、undo log 或大量 binlog；常见错误是误用 DELETE 按条件删除分区表数据。
分区表删除：用 DROP PARTITION 替代 DELETE
如果数据天然按时间、地域或业务维度可划分，分区表是删除海量数据最高效的方式——不是“删数据”，而是“删分区”。DROP PARTITION 是元数据操作，毫秒级完成，不走 InnoDB 行级删除流程，也不生成 undo log 或大量 binlog。
常见错误现象：DELETE FROM logs WHERE log_time 跑了 6 小时，CPU 和 I/O 持续打满，主从延迟飙升。
- 必须提前建好分区表（如按年/月
RANGE或LIST分区），事后无法直接对普通表启用分区 - 分区字段必须出现在
WHERE条件中，且条件需能被 MySQL 的分区裁剪（pruning）识别，否则会扫描所有分区 -
ALTER TABLE ... DROP PARTITION p2022后，磁盘空间不会立即释放（尤其使用innodb_file_per_table=OFF时），需配合OPTIMIZE TABLE或重启实例回收 - 注意：MySQL 8.0+ 支持
TRUNCATE PARTITION，语义更安全（可回滚），但仍是 DDL，会锁整个表
分库分表后删除：为什么不能直接 DROP TABLE？
分库分表本身不加速删除；它只是把单表压力分散。真正提速的是“删整表”这个动作——前提是你要删的是整张逻辑表对应的所有物理分表。
使用场景：日志类冷数据归档后，整套分表（如 logs_202201, logs_202202）都可废弃。
- 逐个执行
DROP TABLE logs_202201等物理表，比在单表上DELETE快得多，但需确保应用层已下线对该分表的读写路由 - 风险点：中间件（如 ShardingSphere、MyCat）可能缓存分表元数据，
DROP后未刷新会导致后续写入失败或写入空表 - 若用 TIDB 或 OceanBase 等 NewSQL，支持更细粒度的“删除分片数据”，但 MySQL 生态中无原生等效能力
- 不要依赖“自动分表中间件”的删除接口——很多只做逻辑标记，底层仍是
DELETE，性能无改善
DROP PARTITION 和 DROP TABLE 的关键区别
两者都是 DDL，但影响范围和恢复难度完全不同：
-
DROP PARTITION只影响一个分区，不影响其他分区查询和写入；DROP TABLE是整表不可用，哪怕只是分表之一，也可能导致业务路由异常 -
DROP PARTITION在 MySQL 5.7 中不可回滚（事务不生效），8.0+ 支持原子性 DDL，但仍无法通过 binlog 回滚；DROP TABLE同理，且没有 binlog 记录表结构前镜像，误删极难恢复 - 监控上，
DROP PARTITION几乎不触发 InnoDB buffer pool 刷脏，而大表DROP TABLE可能引发短暂 IO 尖峰（尤其是innodb_file_per_table=ON时要删 ibd 文件）
分区表删除前最容易被忽略的三件事
很多人建了分区表，却在删除时卡住或失效，问题往往出在前置检查上：
- 确认分区表达式是否可裁剪：执行
EXPLAIN PARTITIONS SELECT * FROM logs WHERE log_time ，看 <code>partitions列是否只显示目标分区（如p2022），而不是all - 检查分区字段类型与查询条件是否严格一致：比如分区字段是
DATETIME，但条件用了字符串'2023-01-01'（隐式转换可能导致裁剪失败） - 验证当前 MySQL 版本对分区操作的支持：MySQL 8.0.29+ 才完整支持
REORGANIZE PARTITION后再DROP，旧版本遇到非对齐分区边界可能报错
