DELETE语句中WHERE条件必须显式指定日期比较，直接写DELETE FROM table_name WHERE date_column会导致语法错误，因缺少比较操作符和值。
DELETE语句中WHERE条件必须显式指定日期比较
直接写 DELETE FROM table_name WHERE date_column 是最常见也最可靠的做法。注意：不能省略 <code>WHERE，否则会清空整张表；也不能依赖默认排序或隐式类型转换——MySQL 或 PostgreSQL 对字符串日期的自动解析行为不一致，SQL Server 甚至可能报错。
常见错误现象：DELETE FROM logs WHERE created_at 在某些数据库里因格式不匹配返回 0 行影响，实际没删任何数据；还有人误写成 <code>created_at ，结果把当天记录也删了。
- 用标准 ISO 格式
'YYYY-MM-DD'（如'2023-01-01'），避免斜杠、点号或中文分隔符 - 确认字段类型是
DATE、DATETIME或TIMESTAMP；如果是字符串（VARCHAR），先用STR_TO_DATE()（MySQL）、TO_DATE()（PostgreSQL）转再比较 - 执行前务必先用
SELECT COUNT(*) FROM table_name WHERE date_column 验证范围
大表删除要加索引，否则可能锁表超时
当表有几百万行，且 date_column 没索引时，DELETE 会全表扫描，不仅慢，还可能触发锁等待或事务超时。PostgreSQL 默认事务超时是 60 秒，MySQL 的 innodb_lock_wait_timeout 默认 50 秒，超出就报错 Lock wait timeout exceeded。
使用场景：日志表、操作审计表、订单历史表——这些通常按时间范围查询和清理，但建表时容易忽略索引。
- 加索引命令示例：
CREATE INDEX idx_logs_created_at ON logs(created_at) - 如果表正在高并发写入，建议在低峰期建索引，或用
CONCURRENTLY（PostgreSQL）避免锁表 - MySQL 8.0+ 支持不可见索引，可先建为
INVISIBLE测试效果再启用
分批删除防止长事务和主从延迟
一次性删几十万行，会导致事务日志暴涨、主库 binlog 写入卡顿、从库重放延迟飙升。尤其在 MySQL 主从架构下，一个大事务可能让从库落后数小时。
参数差异：不同数据库的“一批”合理大小不同——MySQL 建议每批 ≤ 1000 行；PostgreSQL 可放宽到 5000–10000；SQL Server 需配合 TOP (n) 和循环。
- MySQL 示例：
DELETE FROM logs WHERE created_at ，循环执行直到影响行为 0 - PostgreSQL 推荐用 CTE +
WITH ... DELETE控制批次，避免重复扫描 - 一定要在循环逻辑里加
SLEEP(0.1)或类似延时，减轻 I/O 压力
TRUNCATE不能带WHERE，别和DELETE混用
TRUNCATE TABLE logs 快，但不支持条件，也不走事务日志（无法回滚），还会重置自增 ID。有人看到“清历史”就想用它，结果把全部数据都丢了。
性能影响：TRUNCATE 是 DDL 操作，在 PostgreSQL 中会获取 ACCESS EXCLUSIVE 锁，阻塞所有读写；MySQL 中虽快，但无法按日期筛选。
- 只有确认要清空整张表时才用
TRUNCATE，且必须提前备份 - 想保留最近 N 天数据？只能用
DELETE+WHERE，或者导出再重建分区表（适用于支持时间分区的引擎，如 MySQL 8.0+ 的 RANGE 分区） - 某些云数据库（如阿里云 PolarDB）限制 TRUNCATE 权限，默认只开放 DELETE
真正麻烦的是跨时区字段和夏令时边界——比如 created_at 存的是 UTC，但业务要求删“北京时间 2023 年以前”，这时不能简单比 '2023-01-01'，得先转时区再比较。这个细节，上线前最容易漏测。
