分区表删除比DELETE快，但必须确认分区键和执行计划，直接执行DELETE FROM logs WHERE dt。
分区表删除比 DELETE 快，但必须确认分区键和执行计划
直接
或
）做了范围/列表分区，且查询能命中分区键。
用
验证是否“Partition Elimination”：输出里要有
这类明确提示，否则仍是全表扫描
MySQL 8.0+ / PostgreSQL / ClickHouse 支持
，但语法差异大：
（MySQL） vs
（ClickHouse）
PostgreSQL 的
系统视图可查当前分区结构，别靠猜
非分区表只能走 TRUNCATE + 重命名，但需绕过外键和复制延迟
如果日志表没分区，又不能停写，
不可行，
又会阻塞所有 DML。这时得用“交换表”策略：建新空表 → 重命名旧表为备份 → 重命名新表为原名 → 异步删备份表。
MySQL 中
是原子操作，不锁原表读写
务必提前禁用外键检查：
，否则重命名失败
备份表删除必须在从库延迟 SHOW SLAVE STATUS 的
判断
别用
一步到位——先
释放空间再删，避免磁盘 IO 突增
轮转策略要绑定应用层写入路由，否则新数据仍进旧表
光清老数据没用。如果应用还在往
表写，下个月又爆满。轮转本质是让写入自动落到新表，核心在应用配置，不在数据库DDL。
用表名带时间后缀（
）时，应用必须根据当前日期动态拼接表名，不能硬编码
MySQL 分区表的
分区是陷阱：它会吞掉所有越界数据，导致本该进新表的数据滞留在旧分区，必须定期
ClickHouse 的
虽支持 TTL 自动删，但只清理数据不缩容，得配合
手动触发合并
误删恢复依赖备份粒度，不是靠 binlog 回滚
分区
或
后，binlog 里只有 DDL 语句，没有逐行数据，根本没法按条件回滚。真要恢复，得看备份策略是否覆盖到具体分区。
物理备份（xtrabackup / pg_basebackup）必须包含被删分区对应的数据文件路径，例如 MySQL 的
逻辑备份（mysqldump）若用了
，可能漏掉分区定义，还原后表是空壳
别信“删完立刻停服务就能从 binlog 恢复”——只要主库还在写，binlog 就持续滚动，定位精确位点极难
分区边界、应用写入路由、备份有效性，这三个点任何一个没对齐，删得再快也是埋雷。实际操作前，先在从库上用相同语句跑一遍，看
和磁盘 IO 变化。
DELETE FROM logs WHERE dt 在亿级表上会锁表、生成巨量 WAL、拖垮主从同步。真正安全的做法是按分区裁剪——前提是表已按时间字段（如 dtcreate_timeEXPLAINPartitions: p202212,p202211ALTER TABLE ... DROP PARTITIONDROP PARTITION p202212TRUNCATE PARTITION p202212pg_partitioned_tableDELETETRUNCATERENAME TABLE logs TO logs_bak_202405, logs_new TO logsSET FOREIGN_KEY_CHECKS = 0Seconds_Behind_MasterDROP TABLE logs_bak_202405OPTIMIZE TABLE logs_bak_202405logslogs_202405INSERT INTO logsMAXVALUEREORGANIZE PARTITIONReplacingMergeTreeOPTIMIZE TABLE ... FINALDROPTRUNCATE./logs/#P#p202212.ibd--skip-triggers --skip-routinesEXPLAIN