Pourquoi utiliser innodb_file_per_table?
Parce qu'il est plus facile à gérer individuellement car cela peut être fait au niveau du fichier. Cela signifie que même si le serveur est en panne, vous pouvez toujours copier des données en copiant les fichiers de table tandis que l'utilisation d'un espace table partagé signifie soit copier tout ce qui peut être inutilement massif, soit trouver un moyen de faire fonctionner le serveur pour extraire des données ( vous ne voulez vraiment pas extraire manuellement les données avec un éditeur hexadécimal).
Quelqu'un a averti que vous ne pouvez pas simplement copier et coller des .ibdfichiers d'un serveur à un autre. Cela peut être vrai, mais cela ne devrait pas s'appliquer aux sauvegardes sur le même serveur (j'utilise ici le terme sauvegarde dans le sens traditionnel de faire une copie, c'est-à-dire ne pas changer radicalement le tout). De plus, il ibdata1est automatiquement recréé au démarrage (comme le montre l' étape de suppressionibdata1 de la plupart des guides de «conversion en fichier par table»). En tant que tel, vous n'avez pas besoin de copier ibdata1en plus de vos .ibdfichiers (et leurs .frmfichiers correspondants , etc.).
Si vous essayez de récupérer une table perdue, il devrait être suffisant de copier ses fichiers .ibdet .frm, ainsi que information_schema(ce qui est beaucoup plus petit que ibdata1). De cette façon, vous pouvez les mettre dans un serveur factice et extraire votre table sans avoir à copier le tout, chose massive.
Cependant, la revendication d'une meilleure performance est discutable. … Avec innodb_file_per_table, davantage d'opérations d'E / S disque sont nécessaires; et cela est important dans les contraintes complexes JOINs et FOREIGN KEY.
Sans surprise, les performances dépendront entièrement de la ou des bases de données spécifiques utilisées. Une personne aura (même considérablement) des résultats différents d'une autre.
Il est vrai qu'il y aura plus d'opérations d'E / S disque avec fichier par table, mais seulement légèrement plus. Pensez au fonctionnement du système.
Vous remarquerez que lorsque le serveur est en cours d'exécution, vous ne pouvez pas déplacer les fichiers de données car le serveur a des poignées ouvertes vers eux. En effet, quand il démarre, il les ouvre et les laisse ouverts. Il ne les ouvre et ne les ferme pas pour chaque requête individuelle.
En tant que tel, il n'y a que quelques opérations d'E / S supplémentaires au début, lorsque le serveur démarre; pas pendant qu'il fonctionne. De plus, bien que chaque .ibdfichier individuel ait sa propre surcharge distincte (signatures de fichiers, structures, etc.), ils sont mis en cache en mémoire et ne sont pas relus pour chaque requête. De plus, les mêmes structures sont lues même avec un espace table partagé, donc il n'y a pratiquement pas (voire pas du tout) de mémoire supplémentaire requise.
Innodb_file_per_table a-t-il un effet sur une meilleure performance de mysql?
En fait, si quoi que ce soit, la performance peut en fait être pire .
Lorsque vous utilisez un espace table partagé, les opérations de lecture et d'écriture peuvent parfois / souvent être combinées de sorte que le serveur lit un échantillon de données de plusieurs tables en une seule fois ibdata.
Cependant, si les données sont réparties sur plusieurs fichiers, il doit alors effectuer une opération d'E / S distincte pour chacun individuellement.
Bien sûr, cela dépend à nouveau entièrement de la base de données en question; l'impact sur les performances réelles dépendrait de la taille, de la fréquence des requêtes et de la fragmentation interne de l'espace table partagé. Certaines personnes peuvent remarquer une grande différence tandis que d'autres ne voient aucun impact.
L'espace disque logique est partagé sur des ibdata uniques; comment des espaces de table dédiés pour des tables séparées peuvent économiser de l'espace disque?
Ce ne est pas. Si quoi que ce soit, cela augmente l'utilisation du disque.
Je n'ai pas de base de données de 60 Go pour tester, mais ma base de données personnelle «dérisoire» qui contient mon installation WordPress et quelques petites tables pour un usage personnel et des tests de développement pesait environ 30 Mo tout en utilisant un espace table partagé. Après l'avoir converti en fichier par table, il a gonflé à ~ 85 Mo. Même en supprimant tout et en réimportant, c'était toujours> 60 Mo.
Cette augmentation est due à deux facteurs:
La taille minimale absolue pour ibdata1est, pour une raison quelconque, de 10 Mo, même si vous n'y avez rien d'autre que information_schemastocké.
Avec un espace table partagé, ibdata1n'a que des frais généraux comme les signatures de fichiers, les métadonnées, etc., mais avec chaque table, chaque .ibdfichier individuel a tout cela. Cela signifie que le total (même avec une hypothétique <10 Mo ibdata1) serait un peu plus élevé d'au moins:
GetTotalSizeofOverhead() * GetNumTables()
Évidemment, ces augmentations ne vont pas être énormes (sauf si vous utilisez un hôte qui limite la taille de votre base de données ou les stockez sur un lecteur flash, etc.), mais elles augmentent néanmoins, et tout en basculant ( chaque ) table vers un fichier -par table, vous pouvez réduire ibdata1à 10 Mo, le total global sera toujours plus qu'il ne l'était.