保持TYPO3系统日志整洁的最佳方法？

我有这个MySQL

从系统日志中删除 其中sys_log.tstamp是的

---

另请参见“关于保持TYPO3安装干净和小”

为此有一个调度程序任务

它被称为表垃圾收集调度器

在TYPO3 4.7中，它只能清理系统日志表。从TYPO3 6.0开始，它还可以清理sys_历史记录表。您可以配置要清理的天数和表

分机可以注册更多的表格进行清理。

是和否

如果你关心你的历史记录，那就不是了。 您可以使用sys_history表还原对记录内容、页面等的更改。系统历史记录表和系统日志表是相关的。截断sys_log时，也会失去回滚系统更改的能力。你的客户可能不喜欢这样

如果您只关心系统日志大小，则会出现这种情况。 通过cron截断表是可以的

在TYPO3 4.6及更高版本中，您可以使用表垃圾收集调度程序任务als pgampe说。对于4.5以下的TYPO3版本，可以使用扩展名。如果您从系统日志中删除所有早于[N]天的记录，您还将保留记录历史[N]天。对我来说，这似乎是最好的解决办法

---

首先，请尝试修复填充系统日志的内容-

大型系统日志表的另一个常见原因是TYPO3安装中使用的一个扩展中的问题/错误

使用旧版本tx_solr时的常见示例：

这组记录大约每分钟会在sys_log中弹出一次，从而在短时间内生成数百万条记录

幸运的是，这些记录对sys_history中的记录历史和相关的回滚功能没有任何影响，因此删除它们是安全的

如果您有一个较大的系统日志，这可能会导致锁定超时问题，因此您必须限制删除查询：

从系统日志中删除，其中“核心：%”等详细信息限制200000

看

简短答复:

不，这绝对不是一个好主意，除非你使用的是typo39或更高版本，请参阅本文底部的注释。如果您真的想从sys_日志中删除内容，请记住sys_历史仍在引用它。你也应该为系统历史做同样的事情

或者，只需执行以下操作：

DELETE FROM sys_log WHERE NOT EXISTS 
(SELECT * FROM sys_history WHERE sys_history.sys_log_uid=sys_log.uid) 
AND recuid=0 AND tstamp < $timestamp LIMIT $limit 

您可以根据自己的需求自由地优化它

在不影响sys_历史记录的情况下，您还可以安全地删除带有sys_log.error！=0

还有一些建议：

将调试级别设置为开发时出现详细警告，但仅在生产时出现错误 定期查看系统日志并排除问题。解决问题后，您可以从sys_日志中删除特定错误。请参阅sys_log.error！=0，系统日志。详细信息。您可以使用数据库命令或在较新的TYPO3版本上使用SYSTEM:登录后端并使用“删除类似错误”按钮： 您还可以考虑，使用低级清洁器做一个截断的SysLyc和截断SysScript历史，并在一个大版本升级中删除具有删除＝1的记录。不过，一定要先和编辑身边的人谈谈，因为这会删除整个历史。确保你会想这样做。

---

有关调度程序任务表垃圾回收的信息，请参阅文档：

我在答案中添加了名称和几个字。在typo3 4.7.8中，由于调度程序扩展中存在各种错误，无法从后端调度此任务。请看bug，diff:cronjob实际上是一个动词吗？不，它是一个名词。这是我的工作。临时工。虽然我个人并不介意这里的创意词。如果您不介意，要不要编辑？一个快速评论-IIRC有一个调度程序作业，因此您可以在TYPO3安装中保持内部清洁，并且不需要运行不同的外部cli作业，如果我同时截断sys_日志和sys_历史呢？！回滚的能力是有效的？不@Andrea_86。如果截断系统历史记录，则会丢失回滚功能。

Since TYPO3 9, the history is no longer stored using sys_log.
You can safely delete records from sys_log.

DELETE FROM sys_log WHERE NOT EXISTS 
(SELECT * FROM sys_history WHERE sys_history.sys_log_uid=sys_log.uid) 
AND recuid=0 AND tstamp < $timestamp LIMIT $limit