直接DELETE会引发雪崩，安全路径是分批删除：必须ORDER BY主键+LIMIT+索引，每批后COMMIT并SLEEP，避免全表扫描与锁升级。

直接 DELETE FROM logs WHERE dt 在亿级表上不是删数据，是触发数据库雪崩——锁表、日志暴涨、主从延迟飙升、甚至被 DBA 杀掉连接。真正安全的路径只有一条：把大事务切碎，每批控制在可提交、可释放、可监控的粒度。

MySQL 分段删除必须带 ORDER BY + LIMIT

不加 ORDER BY 的 DELETE ... LIMIT 是伪分批：MySQL 优化器可能每次扫描顺序不同，导致重复删或漏删，尤其在并发写入时。更糟的是，没索引支撑的 ORDER BY 会触发 filesort，让 IO 直接拉满。

• 正确写法：DELETE FROM logs WHERE create_time
• id 必须有索引（通常是主键），否则排序成本远超删除本身
• 别用 OFFSET（如 LIMIT 10000, 5000），偏移越大越慢，且中间插入新行会导致跳过
• 每批后必须 COMMIT，否则 InnoDB 不释放 undo log 和行锁

SQL Server 中用 TOP + WAITFOR 控制日志压力

SQL Server 的 DELETE 默认全量进一个事务，每行都记完整日志。不控制就等于往日志文件里狂灌水，Transaction log is full 报错几乎是必然结果。

• 必须写成：DELETE TOP (5000) FROM logs WHERE create_time
• ORDER BY id 不可省——没确定性排序，TOP 无法保证下一批不重复处理同一行
• 每次删完立刻 WAITFOR DELAY '00:00:00.1'，给 CHECKPOINT 和日志截断留出窗口
• 用 @@ROWCOUNT 判断是否继续，别查 EXISTS(SELECT ...)，它可能扫全表

PostgreSQL 大删慎用 LIMIT，优先走主键区间切片

PostgreSQL 的 DELETE ... LIMIT 在高并发下行为不稳定：新插入的行可能挤进下一批范围，导致漏删；同时 LIMIT 不影响 MVCC 扫描路径，仍可能触发全表膨胀。

• 更稳的做法是先查边界：SELECT MIN(id), MAX(id) FROM logs WHERE create_time
• 再按步长分段删：DELETE FROM logs WHERE id BETWEEN 100001 AND 105000
• 步长建议 1000–5000，超过 10000 容易让单次事务 undo 占用过高
• 删完立刻执行 ANALYZE logs，否则后续查询可能因统计信息陈旧而选错执行计划

所有方案都绕不开的硬约束：外键、复制延迟与备份恢复

再完美的分批逻辑，撞上外键或主从延迟，照样失败。而且删完发现错了？别指望 binlog 或 WAL 回滚——DROP PARTITION 或 TRUNCATE 后只有 DDL 记录，没有逐行数据快照。

• 涉及外键的表，删前必须 SET CONSTRAINTS ALL DEFERRED（PostgreSQL）或临时禁用检查（MySQL：SET FOREIGN_KEY_CHECKS = 0）
• 删分区或大表前，先看从库延迟：SHOW SLAVE STATUS 中的 Seconds_Behind_Master 必须接近 0
• 物理备份（xtrabackup / pg_basebackup）必须覆盖被删分区对应的数据文件路径，例如 MySQL 的 ./logs/#P#p202212.ibd
• ClickHouse 的 ReplacingMergeTree TTL 删除后，必须手动 OPTIMIZE TABLE ... FINAL 才能真正缩容

最常被忽略的一点：分批只是“怎么删”，但没解决“为什么还会再爆”。如果应用层没改写入路由，下个月老数据照进，删得再勤也是白忙。轮转策略的核心不在 SQL，而在应用配置是否动态拼接表名或路由到新分区。