doctrine事件监听器不是定时任务调度器，监听器中写sleep或时间判断会失效且阻塞主线程；正确做法是将清理逻辑抽成symfony命令，由crontab独立调度，并确保分批删除、日志记录与生产验证。
监听器里直接写定时逻辑会失效
Doctrine 事件监听器（如 onFlush、postLoad）是响应 ORM 操作的，不是定时任务调度器。往监听器里塞 sleep()、time() + 3600 或循环检查时间，既不可靠（请求生命周期短、无常驻进程），又容易阻塞主线程、拖慢接口响应。
常见错误现象：php bin/console cache:clear 后清理没发生；高并发时部分请求触发多次清理；日志里看到“PHP Warning: max_execution_time exceeded”。
- 监听器只在实体被加载/刷新/持久化时触发，和时间无关
- 不能依赖
$_SERVER['REQUEST_TIME']做周期判断——每次 HTTP 请求都是新上下文 - 若真要在监听器中触发清理，只能作为“被动钩子”，比如用户登出时顺带清掉其访问日志，而非“每小时自动清”
真正可行的清理路径：用独立命令 + crontab
把清理逻辑抽成 Symfony 控制台命令（如 app:cleanup-access-logs），再由系统级 crontab 调度，才是稳定、可监控、可复现的方式。
示例命令结构：
php bin/console app:cleanup-access-logs --days=7 --env=prod
关键点：
- 命令内使用
$em->createQuery()或原生 SQL 批量删除，避免find()+remove()循环（易 OOM） - 加
--dry-run参数预览将删多少行，上线前必跑 - crontab 表达式要严格匹配目标时间，例如每天凌晨 2:15 执行：
15 2 * * * /usr/bin/php /var/www/app/bin/console app:cleanup-access-logs --days=7 --env=prod >> /var/log/symfony-cleanup.log 2>&1 - 日志重定向必须显式写全，否则失败无声无息
为什么不用 Doctrine 的 QueryBuilder 做“自动过期”查询？
有人想在 Repository 查询里加 $qb->where('a.createdAt setParameter('cutoff', new \DateTime('-7 days')) 来“假装清理”，这只能过滤读取结果，不释放磁盘空间，也不降低表体积和索引压力。
真实影响：
- 未清理的数据仍参与 MySQL 的 B+ 树遍历、统计信息计算、备份体积膨胀
- 即使加了
created_at索引，DELETE FROM access_log WHERE created_at 仍比 SELECT 快得多——InnoDB 可直接 truncate page - 长期不清，
access_log表可能从几千行涨到百万级，导致SELECT COUNT(*)类统计查询变慢数秒
清理前必须确认的三件事
跳过任一环节，都可能导致误删、锁表或主从延迟飙升：
- 确认该表没被其他服务（如 BI 工具、日志采集 agent）直连查询 —— 查
SHOW PROCESSLIST和应用层连接池配置 - 确认
access_log表引擎是 InnoDB（非 MyISAM），否则DELETE会锁全表；必要时改用pt-archiver分批归档 - 生产环境首次运行前，在从库上先执行一遍，观察
Seconds_Behind_Master是否突增；若超过 60 秒，说明语句太重，需拆成每 1000 行一批
最常被忽略的是归档替代方案：比起直接 DELETE，用 INSERT INTO archive_access_log SELECT ... FROM access_log WHERE ... 再 DELETE，能保留原始数据用于审计，且对线上查询干扰更小。
