postgresql等效写法为：where created_at

MySQL 中用 DELETE 配合 WHERE timestamp 最直接

时间戳字段类型必须是 DATETIME 或 TIMESTAMP，否则 DATE_SUB 无法正确比较。如果存的是 Unix 时间戳（整型秒数），得先转成日期：FROM_UNIXTIME(timestamp_col) 。注意别漏掉 <code>WHERE 条件——没加条件就是全表删除，线上事故高发点。

• 测试时先用 SELECT COUNT(*) 确认要删多少行，比如：SELECT COUNT(*) FROM logs WHERE created_at
• 大表建议加索引：在时间字段上建普通索引，ALTER TABLE logs ADD INDEX idx_created_at (created_at)
• 避免锁表太久：单次删太多行会阻塞写入，可分批删，例如每次删 1000 行，用 LIMIT 1000 + 循环

Linux 下用 crontab 调用 mysql -e 执行清理语句

别把 SQL 写进 crontab 一行里硬编码，容易出引号和空格问题。推荐写成独立脚本，再由 cron 调用。脚本里用 mysql -u user -p'password' -D db_name -e "DELETE ..."，密码明文虽不安全但最简单；生产环境应改用配置文件方式，把凭证放 ~/.my.cnf 并设 chmod 600。

• crontab 示例（每天凌晨 2 点执行）：0 2 * * * /path/to/clean_logs.sh >> /var/log/clean_logs.log 2>&1
• 脚本开头加 #!/bin/bash，并确保有执行权限：chmod +x clean_logs.sh
• 务必重定向输出，否则失败时你根本不知道 cron 没跑起来

PostgreSQL 怎么写等效的过期清理？用 current_timestamp 和 INTERVAL

PostgreSQL 不支持 DATE_SUB，对应写法是：WHERE created_at 。如果字段是 <code>bigint 存毫秒时间戳，得用 to_timestamp(created_at/1000.0) 转换，注意除以 1000.0 强制浮点运算，否则整除会丢精度。

• PostgreSQL 删除大表更需谨慎：默认事务下删百万行会撑爆 WAL，建议加 COMMIT 分批次，或用 TRUNCATE ... RESTART IDENTITY（仅适用于清空+重置场景）
• 用 pg_stat_progress_delete 视图可查正在执行的 DELETE 进度（v12+）
• 避免在高峰时段运行，VACUUM 延迟可能影响查询性能

为什么不能只靠数据库自动 TTL？Redis EXPIRE 和 MongoDB expireAfterSeconds 不通用

MySQL、PostgreSQL 原生不支持字段级 TTL，所谓“自动过期”只是某些 NoSQL 的特性。Redis 的 EXPIRE 是针对 key 的，适合缓存类数据，不适合主库持久化记录；MongoDB 的 expireAfterSeconds 要求字段是 Date 类型且建 TTL 索引，但删除动作由后台线程异步触发，延迟不可控，不适合强时效清理场景。

• 业务关键数据必须用主动定时 SQL 清理，才能保证精确时间和可观测性
• 若用 Redis 缓存了这些记录，记得在删 DB 后同步 DEL 对应 key，否则出现脏读
• 所有定时清理任务，必须配监控：检查日志中是否出现 ERROR 1205（死锁）或影响行数为 0（可能条件写错或索引失效）

实际跑起来之后，最容易被忽略的是时区——NOW() 和 current_timestamp 默认用数据库服务器时区，而你的业务时间逻辑可能按 UTC 或东八区算，差一小时就可能多删或漏删一天的数据。