这是个非常接地气的问题——很多系统在迭代到一定阶段，都会遇到需要追踪记录访问情况、清理闲置数据的需求。我结合实际项目踩过的坑和行业通用的最佳实践，给你梳理下可行的方案：

1. 表字段+应用层封装（最常用的基础方案） #

这是大多数中小系统的首选，实现直接且容易维护：

• 第一步：给目标表添加时间字段

  -- MySQL/PostgreSQL通用
  ALTER TABLE your_target_table ADD COLUMN last_read_at TIMESTAMP NULL DEFAULT NULL;
  

• 第二步：在应用层封装读取逻辑：每次业务代码查询单条或批量记录后，额外执行一条更新语句，把对应记录的last_read_at设为当前时间。如果是批量读取，可以用IN子句批量更新：

  UPDATE your_target_table 
  SET last_read_at = CURRENT_TIMESTAMP 
  WHERE id IN (?, ?, ?); -- 这里填本次读取的记录ID列表
  

• 注意：如果担心实时更新的性能开销，可以用异步更新（比如把更新请求丢到消息队列，后台异步执行），但要接受last_read_at有一定延迟的 trade-off。
• 优点：逻辑简单，数据直接关联到记录本身，查询访问时间非常方便。
• 缺点：每次读取都伴随写操作，高并发读取场景下会增加数据库负载。

2. 离线日志+批量更新（适合高并发场景） #

如果你的系统有极高的读取QPS，实时更新每条记录的访问时间会成为性能瓶颈，这种方案更合适：

• 思路：不实时更新主表，而是在应用层记录每次读取的「记录ID+访问时间」到一个临时日志表/Redis队列中，然后通过定时任务（比如每天凌晨）批量聚合这些日志，更新主表的last_read_at字段。
• 示例流程：
  • 读取记录时，向日志表插入一条数据：INSERT INTO access_log(record_id, access_time) VALUES (?, CURRENT_TIMESTAMP);
  • 定时任务执行聚合更新：

    WITH latest_access AS (
      SELECT record_id, MAX(access_time) AS latest_time
      FROM access_log
      WHERE access_time >= NOW() - INTERVAL 1 DAY -- 只处理当天的日志
      GROUP BY record_id
    )
    UPDATE your_target_table t
    JOIN latest_access la ON t.id = la.record_id
    SET t.last_read_at = la.latest_time;
    

• 优点：把实时写操作转化为批量离线操作，大幅降低主库负载。
• 缺点：last_read_at的数据有延迟，不适合需要实时获取最新访问时间的场景。

3. 数据库审计日志辅助（无侵入方案） #

如果不想修改业务代码或表结构，可以利用数据库的审计日志功能：

• 开启数据库的行级审计（比如MySQL的审计插件、PostgreSQL的pgAudit），捕获所有读取操作的日志。
• 定期解析审计日志，提取出每条记录的最新访问时间，更新到主表或者单独的统计表里。
• 优点：完全不侵入业务代码，适合已经上线的老系统。
• 缺点：审计日志本身会消耗数据库性能，解析日志的复杂度较高，而且不同数据库的审计配置差异很大。

搞定了访问时间的追踪，接下来就是如何利用这些数据做清理和分析：

1. 分批定时清理（通用安全方案） #

这是最稳妥的清理方式，适合绝大多数场景：

• 核心思路：用定时任务（比如Cron、Airflow）定期扫描表，筛选出过期记录（比如超过90天未访问），分批删除避免锁表。
• 示例SQL（MySQL/PostgreSQL）：

  -- 每次删除1000条，循环执行直到没有符合条件的记录
  DELETE FROM your_target_table 
  WHERE last_read_at < NOW() - INTERVAL 90 DAY 
  LIMIT 1000;
  

• 进阶优化：如果表数据量极大，可以给表按时间分区（比如按月份），直接删除整个分区会比逐行删除高效得多。

2. 行级TTL自动过期（自动化方案） #

部分数据库支持原生的行级TTL（Time To Live）机制，能自动清理过期数据：

• MySQL 8.0+：可以配合事件调度器实现自动清理，或者用Percona Toolkit的pt-archiver工具，它能自动归档并删除过期数据。
• PostgreSQL：可以安装pg_cron插件，定时执行清理任务；或者用pg_partman实现分区自动管理，过期的分区直接删除。
• 优点：自动化程度高，不需要手动维护定时任务的细节。
• 缺点：依赖特定数据库版本或插件，兼容性有限。

3. 热度分层存储（进阶成本优化方案） #

如果你的系统数据量极大，想进一步优化存储成本，可以按访问热度分层管理：

• 分层规则：
  • 热数据：最近7天访问过的，存在高性能主库。
  • 温数据：7-30天访问过的，存在只读库或廉价云存储。
  • 冷数据：超过30天未访问的，归档到对象存储（比如OSS、S3），然后从主库删除。
• 实现方式：定期根据last_read_at统计每条记录的热度，然后写脚本把数据迁移到对应存储层。
• 优点：大幅降低存储成本，同时保证热数据的访问性能。
• 缺点：架构复杂度高，需要额外的迁移、归档和查询路由逻辑。

内容的提问来源于stack exchange，提问作者loxs