delete语句中where条件必须显式指定日期字段和比较运算符，不能仅写delete from table_name where date_column。
DELETE语句中WHERE条件必须显式指定日期字段和比较运算符
直接写 DELETE FROM table_name WHERE date_column 是最常见也最易出错的起点。很多人漏掉 <code>date_column 的存在性验证，或误用字符串格式导致隐式转换失败。MySQL 会尝试把字符串转成日期，但 PostgreSQL 或 SQL Server 可能直接报错 invalid input syntax for type date。务必先确认字段类型是 DATE、DATETIME 还是 TIMESTAMP，再匹配对应格式。
- MySQL 中
'2023-01-01'可自动识别为 DATE；但若字段是DATETIME，建议写成'2023-01-01 00:00:00'避免时区或精度截断 - PostgreSQL 要求严格类型匹配，
date_column::date 比直接比较更稳妥 - SQL Server 建议用
CONVERT(DATE, date_column) ，避免 <code>datetime类型因时间部分被意外排除
大表删除前必须加 LIMIT 或分批执行，否则锁表/超时
线上表数据量超过 10 万行，直接 DELETE 很可能触发长事务、主从延迟飙升，甚至被 DBA 杀掉。MySQL 的 autocommit 默认开启，但单条 DELETE 仍会持锁直到提交——而大删操作本身就会卡住。
- 先用
SELECT COUNT(*) FROM table_name WHERE date_column 估算要删多少行 - 若超过 5000 行，改用循环删除：每次
DELETE FROM table_name WHERE date_column ，查不到新行就停 - PostgreSQL 可配合
WITH ct AS (SELECT id FROM table_name WHERE date_column
WHERE子句里别用函数包裹日期字段，否则索引失效
写成 WHERE DATE(date_column) 看似直观，实际会让 <code>date_column 上的索引完全失效。数据库无法对函数结果做范围扫描，只能全表扫描——100 万行表可能从秒级变分钟级。
- 正确写法永远是让字段单独出现在比较左侧：
date_column - 如果业务逻辑必须按“天”切分（比如只删某天零点前），且字段含时间部分，用
date_column 更高效 - 实在要处理时区，优先在应用层转换时间，而不是在 SQL 里调
CONVERT_TZ()或AT TIME ZONE
删完记得检查并重建索引碎片（尤其 MySQL MyISAM/InnoDB）
大量 DELETE 不会立即释放磁盘空间，InnoDB 会标记页为可复用，但统计信息可能滞后，后续 INSERT/UPDATE 性能下降。MyISAM 则直接留下空洞，SELECT 扫描路径变长。
- MySQL InnoDB：运行
OPTIMIZE TABLE table_name（会锁表，选低峰期） - MySQL MyISAM：同样用
OPTIMIZE TABLE，效果更明显 - PostgreSQL：执行
VACUUM table_name（非阻塞），若删了超 20% 行，再跟一句ANALYZE table_name - 别跳过这步——第二天慢查询告警很可能就来自这里
EXPLAIN 就删生产数据，和没看执行计划就上线是一回事。
