Quelle taille est trop grande pour le fichier ibdata?

Mon fichier ibdata est très volumineux, du moins il me semble très volumineux. Est-ce excessif ou pas si mal?

-rw-rw---- 1 mysql mysql  15G Apr 18 10:11 ibdata1

Quand cela peut être un problème

Si vous exécutez show table statussur une table et que le Data_freechamp représente la grande majorité de ibdata1la taille de votre fichier, vous risquez d'avoir beaucoup d'espace perdu. Beaucoup d'insertions / suppressions en feront un problème. Si tel est le cas et que les insertions et suppressions transitoires constituent la majeure partie de vos données, vous avez un bon cas pour le fichier par table.

Ce n'est pas un "oui" automatique, cependant. Il y a beaucoup de discussions dans le monde sur la fragmentation interne à l'intérieur des fichiers InnoDB, mais les placer dans un système de fichiers en tant que fichier par table déplace simplement votre fragmentation au niveau du système de fichiers au lieu du niveau de la base de données.

Pourquoi ce n'est généralement pas un problème

Considérez votre fichier InnoDB comme un système de fichiers plutôt que comme un fichier. Si vous avez beaucoup de fichiers, vous aurez besoin d'un gros système de fichiers.

Pour la plupart, les systèmes de fichiers réussissent très bien à évoluer pour gérer des téraoctets de données et un nombre incalculable de fichiers. Parfois, ils rencontrent des problèmes d'indexation médiocre (par exemple, des limites au nombre de fichiers dans un répertoire avant un impact sur les performances), mais pour la plupart, le système de fichiers moderne peut basculer bien dans la plage de téraoctets.

InnoDB fonctionne de la même manière. La taille de votre fichier de données peut être énorme ... et comme les grands systèmes de fichiers, cela peut poser des problèmes avec la sauvegarde de vos données. Cependant, tout comme le fractionnement de votre système de fichiers en plusieurs partitions ne résout pas ce problème, ni essayer de manipuler innodb. Bien que vous puissiez utiliser innodb_file_per_table , je le recommande rarement.

Tout comme votre système de fichiers, la meilleure réponse est de connaître les limites en interne et d'y travailler. Comprendre les index et les appliquer correctement. Ne cherchez pas à diviser InnoDB, ce n'est pas fait pour ça.

Étant donné que je m'efforce de transmettre le concept de manière constructive, voici une lecture rapide qui dit mieux que moi les mots: les téraoctets ne sont pas des données volumineuses, les pétaoctets le sont .

Je me souviens d'une diapositive marketing MySQL vraiment très ancienne où le client dirigeait un entrepôt de données avec quelques téraoctets. Il y a plusieurs années. InnoDB ou MyISAM, les deux fonctionneraient. C'est standard sur le rack MySQL.

Ne transpirez pas une base de données de 15 Go.

Les fichiers ibdata ne rétrécissent pas - si vous avez récemment supprimé des tables ou supprimé beaucoup de lignes - innodb dans votre configuration ne libérera pas l'espace libre dans le système de fichiers. je vous suggère:

• sauvegarder toutes vos données, par exemple avec mysqldump
• ajouter à la directive my.cnf innodb_file_per_table
• redémarrer mysql
• supprimer toutes les bases de données à l'aide du moteur innodb
• arrêtez mysql
• supprimer le fichier ibdata
• rm ib_logfile [01]
• démarrez mysql, vérifiez syslog si tout va bien
• recharger votre vidage

de cette façon, vous pourrez récupérer l'espace chaque fois que vous supprimez une table / base de données innodb - les fichiers idb associés seront supprimés immédiatement.