Purge Mediawiki - Page 1

Mon (Media)wiki prend aujourd'hui 87.4 MB de base de données, et se rapproche de la limite des 100 MB de mon hébergement 1and1.

Il n'y a pas tant de choses que ça dessus, par contre il y a eu beaucoup d'éditions en presque 2 ans, je soupçonne les révisions des pages de prendre la majorité de la place (d'autant plus que pas mal de contenu a été supprimé pour être déplacé ailleurs). Les historiques ne m'intéressent pas vraiment, j'aimerais savoir s'il y aurait un moyen de garder uniquement la dernière révision de chaque page. Je n'ai rien trouvé à ce sujet dans la doc.

D'après phpMyAdmin : 2528 ko pour la table 'revision' (qui indique l'historique) et 84496 ko pour la table 'text' (le contenu des révisions) Donc c'est bien ça.

Finalement je me suis débrouillé directemement à partir du modèle de données qui est pas très complexe.

-- Contourne les restrictions sur les lecture de table dans une sous-requête lors d'une màj
CREATE TEMPORARY TABLE tmp_revision (INDEX idx_tmp_revision_timestamp (trev_timestamp), INDEX idx_tmp_revision_page (trev_page))
SELECT rev_page trev_page, rev_timestamp trev_timestamp FROM revision;
 
DELETE revision, text, recentchanges
 FROM revision LEFT OUTER JOIN text ON rev_text_id = old_id
 LEFT OUTER JOIN recentchanges ON old_id = rc_this_oldid
  WHERE rev_timestamp != (SELECT MAX(trev_timestamp) FROM tmp_revision WHERE trev_page = rev_page);
 
TRUNCATE archive;

D'après phpMyAdmin la table text est tombée à 24,1 Mo (ça me paraît toujours élevé...) et revision à 512 Ko.
Reste à l'utiliser quelques jours pour vérifier que j'ai rien cassé.

24Mo de texte ? soit ton wiki est vraiment bien garni soit t'as encore des possibilités de ménage

Ouais, c'est louche.

Ah, c'est bon, text prend maintenant 1.5 Mo, et la base 1.6 Mo
Peut-être qu'InnoDB a des cycles de purges bizarres ? Ca me fait penser que passer en MyISAM ferait peut-être gagner un peu de place ?

C'est dans ta config de mysql ça, innodb propose un mode transactionnel et quand tu l'utilise pas, les données sont conservés jusqu'à un timeout après lequel le rollback n'est plus possible

OK. Mais quel interêt de permettre le rollback alors que je suis en autocommit ?

optimisation du moteur, l'autocommit ou le mode explicite ne doivent pas nécessiter une foultitude de test par requete => on "save" temporairement les données dans le temp...

un OPTIMIZE TABLES ou un FLUS§H TABLES aurait ptet accéléré la réallocation de l'espace utilisé par la base