Est-ce que innodb_file_per_table est conseillé?

19

Nous avons une application où une seule des tables deviendra un million de lignes mais le reste sera juste en dessous d'un million. Alors, quel conseil devrions-nous utiliser avec innodb_file_per_table ou partir comme un seul .ibd? J'ai lu certains articles disant de ne pas y aller car vous avez besoin de plus d'accès au disque quand il y a des jointures à effectuer? Nous aurons une jointure entre cette table et d'autres à des fins de génération de rapports.

newbie14
la source

Réponses:

24

Vous devez aller avec innodb_file_per_table et vous devez faire un peu de nettoyage avec l'infrastructure actuelle d'InnoDB.

J'ai vu de nombreux clients d'hébergement de bases de données configurer MySQL et laisser InnoDB dans son état par défaut. Cela provoque une augmentation considérable de l'espace disque logique du système (mieux connu sous le nom d'ibdata1).

Même si vous êtes passé à innodb_file_per_table, le fichier .ibd devrait être extrait de ibdata1 et ibdata ne rétrécira jamais. Par exemple, si vous avez une table appelée mydb.mytable qui se trouve à l'intérieur d'ibdata1 occupant 2 Go, pour l'extraire, vous devez procéder comme suit:

ÉTAPE 01) Ajoutez ceci à /etc/my.cnf

[mysqld]
innodb_file_per_table

ÉTAPE 02) service mysql restart

ÉTAPE 03) ALTER TABLE mydb.mytable ENGINE=InnoDB;

Cela rendra le fichier /var/lib/mysql/mydb/mytable.ibd

Malheureusement, les 2 Go d'espace occupé par la table avant le changement ne peuvent pas être récupérés. J'ai écrit des articles précédents sur comment et pourquoi nettoyer l'infrastructure d'InnoDB:

Une fois que vous avez effectué ce changement majeur, n'oubliez pas d'augmenter innodb_open_files (300 par défaut) . Sinon, l'accès au disque est très limité.

En ce qui concerne les jointures, assurez-vous de disposer d'index appropriés prenant en charge les critères de jointure.

MISE À JOUR 2012-04-02 11:30 EDT

En utilisant innodb_file_per_table dans une nouvelle installation, ibdata1 se développe très lentement car tout DDL est fait en externe à ibdata. Vous pouvez réduire n'importe quelle table InnoDB comme je l'ai mentionné précédemment comme ceci:

ALTER TABLE mydb.mytable ENGINE=InnoDB;

MISE À JOUR 2012-04-02 16:50 EDT

En ce qui concerne les sauvegardes, soyez extrêmement prudent lors de la copie de fichiers .ibd. Pourquoi?

À l'intérieur de chaque fichier .ibd se trouve une valeur spéciale connue sous le nom de tablespace_id. Il y a une liste de valeurs tablespace_id dans ibdata1. Si vous effectuez une maintenance de table qui nécessite de supprimer et recréer la table, tablespace_id deviendra différent. La copie d'un tel fichier .ibd ne peut être réintégrée dans la base de données pour utilisation que si vous effectuez également une copie d'ibdata1. Cela met en danger le tablespace_id de toutes les autres tables InnoDB. À la lumière de cela, il est préférable d'effectuer des sauvegardes mysqldump car mysqldumps sont des copies logiques des données. En d'autres termes, la sauvegarde est indépendante du point dans le temps de l'ibdata1 et vous êtes libre de recharger sans problèmes d'opérabilité.

RolandoMySQLDBA
la source
cela va être un nouveau serveur. alors que dois-je faire alors? Pourquoi dites-vous qu'il est bon d'aller avec innodb_file_per_table? Au fil du temps, ce tableau augmentera. À quoi faut-il s'attendre pour détecter tout type d'erreur de limite?
newbie14
7

D'accord avec @RolandoMySQLDBA, pour quelque chose qu'il ne mentionne pas: les sauvegardes.

Si votre régime de sauvegarde MySQL a bien fonctionné ET que vous n'incluez pas son fichier .ibd dans votre stratégie de sauvegarde du système de fichiers, ce n'est pas si important. Mais considérez que l'ajout d'un octet à n'importe quelle table innodb entraînera une sauvegarde incrémentielle de votre table .ibd autrement, et vous pouvez voir que vous allez rapidement manquer de stockage de sauvegarde.

Jan Steinman
la source
cher tout oui, je prévois d'exécuter la sauvegarde aussi. si j'ai besoin d'une sauvegarde maître à maître, quelle différence y a-t-il entre le simple maître et l'esclave? Est-ce que les deux se sauvegardent, n'est-ce pas? Sur les paramètres, que faut-il changer?
newbie14
4

J'ai une application où j'ai exactement cette situation: quelques grandes tables et quelques plus petites.

J'ai décidé de laisser les petits dans le ibdata1tout en mettant les plus gros dans leurs propres fichiers.

Je le fais en ayant innodb_file_per_tableactivé par défaut et que l'éteindre temporairement pour déplacer une table ibdata1avec ALTER TABLE.

glglgl
la source
@gigigi comment laisser les petits dans l'ibdata1 et le gros dans leurs propres fichiers n'est-ce pas que si vous définissez ce innodb_file_per_table signifie que tous seront dans leurs propres fichiers?
newbie14
Seulement après toi ALTER TABLE. Donc, ma stratégie est de l'avoir innodb_file_per_tableallumée régulièrement et de l'éteindre avec désinvolture afin de déplacer une petite table ibdata1et de la rallumer ensuite.
glglgl
est-ce bien de rester toujours comme innodb_file_per_table pas un problème ici non?
newbie14
ça