11

私はこの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 を小さく保つのに適していますか?

4

5 に答える 5

10

はいといいえ

あなたがあなたの記録の歴史を気にするなら、それはそうではありません。sys_history テーブルを使用して、レコード (コンテンツ、ページなど) への変更を元に戻すことができます。sys_history テーブルと sys_log テーブルは関連しています。sys_log を切り捨てると、システムへの変更をロールバックする機能も失われます。あなたのクライアントはそれを好まないかもしれません。

sys_logのサイズだけを気にする場合は、ISです。cron を介してテーブルを切り捨てることは問題ありません。

TYPO3 4.6 以降では、テーブル ガベージ コレクション スケジューラ タスク als pgampe を使用できます。TYPO3 のバージョンが 4.5 未満の場合は、tablecleaner拡張機能を使用できます。[N] 日より古いすべてのレコードを sys_log から削除すると、レコード履歴も [N] 日間保持されます。それが私にとって最善の解決策のようです。

そして、最初にsys_logを埋めているものを修正してみてください;-)

于 2013-03-22T10:12:20.590 に答える
7

はい、そうです。

TYPO3のインストールをクリーンで小さく保つことについてのJochen Weilandによる他の提案も参照してください。

于 2012-06-27T17:00:49.037 に答える
7

このためのスケジューラ タスクがあります。

といいTable garbage collection (scheduler)ます。

sys_logTYPO3 4.7 では、テーブルをきれいにすることしかできません。TYPO3 6.0から、sys_historyテーブルをきれいにすることもできます。日数とクリーンアップするテーブルを構成できます。

拡張機能は、クリーニングする追加のテーブルを登録する場合があります。

于 2012-06-29T09:32:36.293 に答える
1

大きなsys_logテーブルのもう 1 つの一般的な原因は、TYPO3 インストールで使用される拡張機能の 1 つの問題/エラーです。

の古いバージョンを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

この一連のレコードは、1 分ごとにポップアップ表示されsys_log、短期間で数百万のレコードにつながります。

幸いなことに、これらの種類のレコードは、のレコード履歴および関連するロールバック機能に影響を与えないsys_historyため、安全に削除できます。

サイズが大きい場合は、タイムアウトのsys_log問題が発生する可能性が高いLOCKため、削除クエリを制限する必要があります。

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

于 2013-05-28T12:43:17.223 に答える