保持TYPO3 sys_log不错的最好方法清洁？

Question

我有这个MySQL

DELETE FROM sys_log 
WHERE sys_log.tstamp < UNIX_TIMESTAMP(ADDDATE(NOW(), INTERVAL -2 MONTH)) 
ORDER BY sys_log.tstamp ASC 
LIMIT 10000

如果我是cronjob，这对于保持sys_log很小很有用吗？

Answer 1

是和否

如果您关心自己的记录历史记录不 。 您可以使用sys_history表还原对记录（内容，页面等）的更改。 sys_history表和sys_log表是相关的。截断sys_log时，您也无法回滚对系统的任何更改。您的客户可能不喜欢这样。

如果您只关心sys_log大小，则 IS 。 通过cron截断表格很好。

在TYPO3 4.6及以上版本中，您可以使用Table垃圾收集调度程序任务，pgampe说。对于低于4.5的TYPO3版本，您可以使用tablecleaner扩展名。如果从[N]天以后的sys_log中删除所有记录，您还将保留[N]天的记录历史记录。这对我来说似乎是最好的解决方案。

请首先尝试修复填充sys_log的内容; - ）

Answer 2

是的，是的。

另见other suggestions by Jochen Weiland关于保持TYPO3安装清洁和小型

Answer 3

这有一个调度任务。

它被称为Table garbage collection (scheduler)。

在TYPO3 4.7中，它只能清除sys_log表。从TYPO3 6.0开始，它还可以清除sys_history表。您可以配置要清理的天数和表。

扩展可以注册更多表来清理。

Answer 4

简答：

不，这绝对不是一个好主意（除非您使用的是TYPO3 9或更高版本，请参阅本文底部的注释）。如果你真的想从sys_log中删除东西，请记住sys_history仍然引用它。您也应该对sys_history执行相同的操作。

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

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_history）是使用sys_log.error！= 0删除记录。

显而易见的答案：

• 在开发中进行测试，而不是生产。消除开发中的错误。训练并训练您的开发人员密切关注此事。
• 在开发时将调试级别设置为详细（警告），但仅在生产中设置错误
• 通过脚本或手动
密切监视sys_log

更多建议：

• 定期查看sys日志并消除问题。一旦处理完问题，就可以从sys_log中删除特定错误（请参阅sys_log.error！= 0，sys_log.details）。您可以使用数据库命令执行此操作，或者在较新的TYPO3版本上使用后端的“SYSTEM：log”并使用“删除类似错误”按钮：

• 您还可以考虑在使用低级清理程序时执行truncate sys_log和truncate sys_history，并在主要版本升级时删除已删除= 1的记录。请务必先与编辑附近的人交谈，因为这样会删除整个历史记录。确保你想要这样做。

在较新的TYPO3版本上，sys_log和sys_history之间不再存在这种关系问题。看看TYPO3 9中的突破变化#55298。

Answer 5

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

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

Core: Error handler (FE): PHP Warning: Invalid argument supplied for foreach() in typo3conf/ext/solr/classes/class.tx_solr_util.php
Core: Error handler (FE): PHP Warning: array_reverse() expects parameter 1 to be array, null given in typo3conf/ext/solr/classes/class.tx_solr_util.php line 280

这一组记录将每隔一分钟左右弹出sys_log，这会在短时间内产生数百万条记录。

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

如果你有一个很大的sys_log，这可能会导致LOCK超时问题，所以你必须限制删除查询：

delete from sys_log where details LIKE 'Core:%' LIMIT 200000;