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.
Réponses:
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.
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;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é.
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.
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.
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.