滑动窗口删除必须基于时间范围而非LIMIT；核心是每次仅删除当前窗口起点之前的数据，窗口随时间向前平移，如保留7天数据则每日删created_at<NOW()-7D的记录。
滑动窗口删除必须用时间范围而非 LIMIT
直接 DELETE ... LIMIT N 无法实现滑动窗口语义——它只管删多少行，不管时间边界。真正滑动的核心是：每次只删「当前窗口起点之前」的数据，且窗口随时间向前平移。比如保留最近 7 天数据，那每天执行时应删掉 created_at 的记录，而不是删固定行数。
常见错误是写成 DELETE FROM logs ORDER BY created_at ASC LIMIT 1000，这会导致旧数据删不干净、新数据误删、窗口不连续。
- 务必用带时间条件的
WHERE，不要依赖LIMIT控制范围 - 时间字段必须有索引，否则全表扫描会锁表、拖慢主业务
- 若表无
created_at或updated_at，先加字段并补全历史值，否则滑动逻辑失效
MySQL 中用 DATE_SUB 配合 WHERE 安全删除
MySQL 不支持窗口函数做删除，但 DATE_SUB(NOW(), INTERVAL N DAY) 是最稳妥的时间计算方式。注意别用 NOW() - INTERVAL N DAY 这种隐式转换，某些版本可能出错；也别用 ADDDATE，语义不如 DATE_SUB 直观。
实操建议分批删除防锁表：
DELETE FROM user_events WHERE created_at < DATE_SUB(NOW(), INTERVAL 30 DAY) LIMIT 10000;
然后在应用层或定时脚本中循环执行，直到影响行为 0。每次删完加 SLEEP(0.1)（如用存储过程）或由调度器控制间隔。
- 避免单次删超 5 万行，否则事务日志暴涨、主从延迟突增
- 确认
created_at列类型是DATETIME或TIMESTAMP，不是VARCHAR，否则索引失效 - 测试时先用
SELECT COUNT(*)验证范围：SELECT COUNT(*) FROM user_events WHERE created_at < DATE_SUB(NOW(), INTERVAL 30 DAY);
PostgreSQL 需显式用 CURRENT_TIMESTAMP 和子查询规避快照问题
PG 的 MVCC 机制下，长事务可能让 CURRENT_TIMESTAMP 在同一事务内多次调用返回不同值，导致部分数据漏删或重复删。安全做法是把时间点固化在子查询里：
WITH cutoff AS ( SELECT CURRENT_TIMESTAMP - INTERVAL '90 days' AS ts ) DELETE FROM audit_log USING cutoff WHERE audit_log.created_at < cutoff.ts;
这样整个删除操作基于一个确定的时间快照，不受外部事务干扰。
- 不要在
WHERE中直接写created_at < CURRENT_TIMESTAMP - INTERVAL '90 days' - 分区表可直接
TRUNCATE过期分区，比逐行删快几个数量级，但需提前按时间建好PARTITION BY RANGE - 如果用逻辑复制，注意
DELETE会产生大量 WAL，必要时调大max_wal_size
滑动窗口的“滑动”必须由外部调度驱动
数据库本身没有内置的滑动触发器。所谓“滑动”，本质是定期执行（如每小时/每天）一条带动态时间边界的 DELETE 语句。这个时间边界不能硬编码，得由调度器传入或由 SQL 动态算出。
最容易被忽略的是时区一致性：应用写入用的是 UTC，但 NOW() 可能返回本地时区时间。务必统一用 UTC_TIMESTAMP()（MySQL）或 CURRENT_UTC_TIMESTAMP（PG 扩展）或显式 AT TIME ZONE 'UTC'。
- 生产环境禁止用
EVENT（MySQL）或pg_cron自动删，除非你完全掌控其并发行为和失败重试逻辑 - 推荐用外部调度器（如 Airflow、Cron + Python 脚本），便于监控、告警、回滚
- 每次执行前记日志：删了哪些时间范围、删了多少行、耗时多久——没日志就等于没滑动
