错误的DELETE WHERE时间条件会导致全表误删；正确写法应为DELETE FROM table WHERE created_at < '指定时间'。
DELETE WHERE 时间条件写错会导致全表误删
直接用 DELETE FROM table WHERE created_at 看似合理，但实际执行前必须确认三点：字段类型是否为 <code>DATETIME 或 TIMESTAMP；时区是否与写入时一致；索引是否覆盖该字段。否则可能扫描全表、执行极慢，甚至因隐式类型转换导致条件失效（比如 created_at 是字符串类型，'2023-01-01' 会被当作字典序比较）。
实操建议：
- 先用
SELECT COUNT(*)验证范围：SELECT COUNT(*) FROM table WHERE created_at - 确保
created_at列有索引：SHOW INDEX FROM table WHERE Key_name = 'idx_created_at' - 避免用函数包裹字段：
WHERE DATE(created_at) 会跳过索引，改用 <code>WHERE created_at - 生产环境务必加
LIMIT分批删：DELETE FROM table WHERE created_at
MySQL 8.0+ 支持分区表自动清理，但必须提前规划
按时间分区（如 RANGE COLUMNS(created_at)）是真正高效的“删除”方式——本质是 DROP PARTITION，毫秒级完成，不走 DML 流程，也不锁全表。但它不能事后添加：表建好就必须定义分区规则，且分区键只能是主键/唯一键的子集。
常见陷阱：
- 分区字段必须是整型或日期类型，不能是
VARCHAR存时间字符串 -
TO_DAYS(created_at)函数在 MySQL 8.0.28+ 已弃用，改用UNIX_TIMESTAMP(created_at)或直接RANGE COLUMNS - 分区数不宜过多（如每天一分区），否则
INFORMATION_SCHEMA.PARTITIONS查询变慢，建议按月或按季度 - 删除旧分区后，记得用
ALTER TABLE table REORGANIZE PARTITION ...补上新分区，否则后续插入会失败
PostgreSQL 用分区表 + 延迟删除更安全
PG 的声明式分区（PARTITION BY RANGE (created_at)）支持直接 DROP TABLE 子分区，但和 MySQL 不同：它不自动维护分区，需手动或通过脚本创建/归档/删除。优势在于可先 DETACH PARTITION 把数据移出再删，留作备份或审计。
关键操作顺序：
- 创建分区时指定
DEFAULT分区兜底，避免插入失败 - 删之前先
ANALYZE目标分区，确保查询计划准确：ANALYZE table_2022_q1 - 用
TRUNCATE替代DELETE更快，但会重置序列，注意关联serial字段 - 若用
pg_partman扩展，配置retention参数后，它会在维护窗口自动DROP过期分区
SQL Server 的 SWITCH 分区本质是元数据操作
SQL Server 分区表删除历史数据最快的方式是 SWITCH：把旧分区切换到一个空表，再 DROP 该空表。整个过程几乎不产生日志、不阻塞 DML，但要求源表和目标表结构完全一致（包括约束、索引、压缩设置）。
容易卡住的点：
- 目标空表必须和源分区在同一文件组，且
ON [PRIMARY]写法不等于物理一致 - 切换前需禁用目标表所有非对齐索引，否则报错
Msg 7735 - 如果原表有
IDENTITY列，目标表也必须有，且种子/增量值要匹配 - 无法跨数据库
SWITCH，归档到其他库需用INSERT INTO ... SELECT+TRUNCATE
真正麻烦的不是语法，而是删完之后的连锁反应：主从延迟突增、备份体积骤减导致校验失败、监控告警阈值失准。这些往往比删数据本身更耗时间。
