Typo3 Datenbank wächst und wächst und wächst

Es gibt Tage, da wundert man sich nur noch. Das SQL-Backup einer Maschine meckert, daß die Datenbank zu groß für ein inkrementelles Upgrade sei. Und wirklich, die Datei ist riesig. Eine einfache Lösung wäre, auf Vollbackup umzustellen. Aber es interessiert uns immer, warum Dinge aus dem Ruder laufen.

Zuerst ein Blick in die Großen der Tabellen. Es ragt "tt_news_cache" heraus. Also mal schauen.

mysql> show fields from tt_news_cache;
+------------+------------------+------+-----+---------+----------------+
| Field      | Type             | Null | Key | Default | Extra          |
+------------+------------------+------+-----+---------+----------------+
| id         | int(11) unsigned | NO   | PRI | NULL    | auto_increment |
| identifier | varchar(32)      | NO   | MUL |         |                |
| content    | text             | NO   |     | NULL    |                |
| crdate     | int(11)          | NO   |     | 0       |                |
| lifetime   | int(11)          | NO   |     | 0       |                |
| tags       | varchar(255)     | NO   | MUL |         |                |
+------------+------------------+------+-----+---------+----------------+
6 rows in set (0.00 sec)

LAMP-typisch ist der Gebrauch von int(11) für Zeitstempel, statt passende Datenbanktypen zu benutzen. Aber was bedeuten denn die? Wie immer ist ein Blick in den Quellcode hilfreich: typo3conf/ext/tt_news/lib/class.tx_ttnews_cache.php enthält die entscheidenden Zeile.

$where_clause .= ' AND (crdate+lifetime>' . $this->ACCESS_TIME.' OR lifetime=0)';

Ein Cache-Eintrag ist also lifetime Sekunden nach dem Erstellungsdatum crdate gültig. Oder eben ewig gültig. Aber die Ewigkeit ignoriere ich erst einmal.

Wie schaut es nun mit der Verteilung der Daten aus? Wieviele Einträge sind aktuell überhaupt gültig?

mysql> select count(*), crdate+lifetime < 1445857535 from tt_news_cache group by 2;
+----------+------------------------------+
| count(*) | crdate+lifetime < 1445857535 |
+----------+------------------------------+
|     8151 |                            0 |
|  4575935 |                            1 |
+----------+------------------------------+
2 rows in set (47.61 sec) 

Wow! Nicht schlecht. Praktisch die gesamte Tabelle enthält unverwertbaren Schrott. Aufräumen scheint man bei tt_news nicht zu kennen. Oder sterben die Webseiten schneller, als die Datenbank platzen kann?

Nun gut, dann räumen ich halt weg.

mysql>; delete from tt_news_cache where crdate+lifetime < 1445857535;
Query OK, 4575935 rows affected (41 min 18.93 sec) 

Das hat gedauert, aber es war erfolgreich.

mysql>; select count(*), crdate+lifetime < 1445857535 from tt_news_cache group by 2;
+----------+------------------------------+
| count(*) | crdate+lifetime < 1445857535 |
+----------+------------------------------+
|     8519 |                            0 |
+----------+------------------------------+
1 row in set (0.20 sec)

Nun darf man das Aufräumen nur nicht wieder vergessen. Die Zeile ist jetzt Bestandteil des täglichen Cronjobs.

Avatar
Lutz Donnerhacke 26/10/2015 5:03 pm
Danke. Guter Tipp.
Avatar
Kristian Köhntopp 26/10/2015 4:23 pm
Nach einem solchen Massen-Delete kann ein OPTIMIZE TABLE nützlich sein, weil es die *.ibd-Datei der Tabelle regeneriert und so dem OS jede Menge Platz zuführt. Die späteren inkrementellen Deletes brauchen das nicht.

Total 2 comments

Post a comment

Related content