Symfony2中创建清理旧数据命令需用php app/console generate:command生成，再在execute()中分批查询删除、加日志、防锁表，并配crontab时指定时区、绝对路径及--env=prod。
直接在 Symfony2 里用 cron 调用自定义命令清理旧数据，是最稳、最可控的方式。别依赖 Doctrine 事件自动触发或 PHP 内部 sleep 轮询——前者不可靠，后者会阻塞请求、吃光内存。
怎么写一个清理旧数据的 Symfony2 命令
用官方生成器起步，避免手动注册服务出错：
- 运行
php app/console generate:command App:CleanupOldDataCommand（Symfony2.8 对应命令名是generate:command，不是make:command） - 编辑生成的类，在
execute()方法里写逻辑：先查再删，别直接DELETE FROM—— 避免锁表和事务失控 - 用
$em->getRepository('AppBundle:Log')->findBy(['createdAt' => $dateRange])拉出要删的实体，再逐个remove()+flush()分批处理（比如每次 100 条） - 加日志输出：
$output->writeln(sprintf('Deleted %d log entries', $count));，方便后续排查是否执行
crontab 怎么配才不漏掉、不重复
关键不是“每天凌晨跑”，而是确保时间表达式与服务器时区一致，且命令路径绝对可靠：
- 确认服务器时区：
date输出是否和你的业务预期一致（如中国是CST，不是UTC）；若不一致，crontab -e顶部加CRON_TZ=Asia/Shanghai - 用绝对路径调用 PHP 和控制台：
0 2 * * * /usr/bin/php /var/www/myapp/app/console app:cleanup-old-data --env=prod - 别省略
--env=prod：开发环境可能禁用某些数据库索引或开启 SQL 日志，导致清理变慢甚至失败 - 加重定向防邮件轰炸：
> /dev/null 2>&1，否则每跑一次 cron 都可能发一封失败通知到 root 邮箱
为什么清理后查询还是卡？重点查这三处
清理旧数据本身不等于提升查询性能。真正影响 “访问路径查询流畅度” 的，往往是残留的副作用：
-
DELETE后没OPTIMIZE TABLE：尤其 MyISAM 或老版本 MySQL，删大量行会导致表碎片，SELECT COUNT(*)类查询明显变慢；建议在命令末尾加$connection->exec('OPTIMIZE TABLE log_table'); - 索引统计信息过期：MySQL 的查询优化器依赖
ANALYZE TABLE更新统计，删完 20% 以上数据后建议手动触发 - 缓存未失效：如果用了 Doctrine 第二级缓存或 Redis 缓存了全量列表，删数据后必须显式清除对应 cache key，否则控制器仍返回旧结果 —— 别指望 ORM 自动处理
最容易被忽略的是：清理命令自己成了慢查询源。务必在 execute() 开头加 $stopwatch = new \Symfony\Component\Stopwatch\Stopwatch(); $stopwatch->start('cleanup');，结尾打点并记录耗时。超过 30 秒的清理任务，就得拆成异步队列或分时段执行——它不该和用户请求共享同一资源池。
