web-dev-qa-db-fra.com

Pourquoi InnoDB stocke-t-il toutes les bases de données dans un seul fichier?

Il était pratique que MyISAM utilise pour stocker chaque table dans un fichier correspondant. InnoDB a fait des progrès dans de nombreux aspects, mais je me demande pourquoi InnoDB stocke toutes les bases de données dans un seul fichier (ibdata1 par défaut).

Je comprends qu'InnoDB cartographiera l'emplacement des données dans le fichier par fichiers d'index individuels pour les tables, mais je ne comprends pas pourquoi il mélange toutes les données dans un seul fichier. Et plus important encore, pourquoi mélanger les données de toutes les bases de données sur le serveur?

Une caractéristique intéressante de MyISAM est que l'on peut copier/coller un dossier de base de données sur une autre machine, puis utiliser la base de données (sans vidage).

mysqlinnodbmysql-5.5mysqldumpmyisam
55
Googlebot

L'architecture d'InnoDB nécessite l'utilisation de quatre types de base de pages d'informations

  • Pages de données de table
  • Pages d'index de table
  • Table MetaData
  • [~ # ~] mvcc [~ # ~] Données (pour prendre en charge l'isolement des transactions et Conformité ACID )
    • Segments de restauration
    • Annuler l'espace
    • Double tampon d'écriture (écriture en arrière-plan pour empêcher la dépendance à la mise en cache du système d'exploitation)
    • Insérer un tampon (gestion des modifications apportées aux index secondaires non uniques)

Voir la représentation picturale d'ibdata1

Par défaut, innodb_file_per_table est désactivé. Cela provoque les quatre types de page d'informations à atterrir un seul fichier appelé ibdata1. Beaucoup de gens essaient de diffuser les données en créant plusieurs fichiers ibdata. Cela pourrait entraîner une fragmentation des données et des pages d'index.

C'est pourquoi j'ai souvent recommande de nettoyer l'infrastructure InnoDB, en utilisant le fichier ibdata1 par défaut et rien de plus .

La copie est très dangereuse en raison de l'infrastructure sous laquelle InnoDB fonctionne. Il existe deux infrastructures de base

  • innodb_file_per_table désactivé
  • innodb_file_per_table activé

InnoDB ( innodb_file_per_table désactivé)

Avec innodb_file_per_table désactivé, tous ces types d'informations InnoDB vivent dans ibdata1. La seule manifestation d'une table InnoDB en dehors d'ibdata1 est le fichier .frm de la table InnoDB. La copie de toutes les données InnoDB à la fois nécessite la copie de tout/var/lib/mysql.

La copie d'une table InnoDB individuelle est totalement impossible. Vous devez effectuer un vidage MySQL pour extraire un vidage de la table en tant que représentation logique des données et des définitions d'index correspondantes. Vous devez ensuite charger ce vidage dans une autre base de données sur le même serveur ou un autre serveur.

InnoDB ( innodb_file_per_table activé)

Avec innodb_file_per_table activé, les données de la table et ses index vivent dans le dossier de la base de données à côté du fichier .frm. Par exemple, pour la table db1.mytable, la manifestation de cette table InnoDB en dehors d'ibdata1 serait:

  • /var/lib/mysql/db1/mytable.frm
  • /var/lib/mysql/db1/mytable.ibd

Espace disque logique du système ibdata1

Toutes les métadonnées de db1.mytable résident toujours dans ibdata1 et il n'y a absolument aucun moyen de contourner cela. Les fichiers de journalisation et les données MVCC vivent également avec ibdata1.

En ce qui concerne la fragmentation des tables, voici ce qui arrive à ibdata1:

  • innodb_file_per_table activé : vous pouvez réduire db1.mytables avec ALTER TABLE db1.mytable ENGINE=InnoDB; ou OPTIMIZE TABLE db1.mytable;. Il en résulte que /var/lib/mysql/db1/mytable.ibd est physiquement plus petit sans aucune fragmentation.
  • innodb_file_per_table désactivé : vous ne pouvez pas réduire db1.mytables avec ALTER TABLE db1.mytable ENGINE=InnoDB; ou OPTIMIZE TABLE db1.mytable; car il réside avec ibdata1. L'exécution de l'une ou l'autre commande rend la table contiguë et plus rapide à lire et à écrire. Malheureusement, cela se produit à la fin d'ibdata1. Cela permet à ibdata1 de croître rapidement. Ceci est entièrement traité dans mon post de nettoyage InnoDB .

AVERTISSEMENT (ou DANGER comme le robot dirait dans Lost in Space )

Si vous songez à copier simplement les fichiers .frm et .ibd, vous êtes en ligne pour le monde du mal. La copie des fichiers .frm et .ibd d'une table InnoDB n'est bonne que si et seulement si vous pouvez garantir que l'ID d'espace de table du fichier .ibd correspond exactement à l'ID d'espace de table entrée dans les métadonnées du fichier ibdata1.

J'ai écrit deux articles dans DBA StackExchange sur ce concept d'ID d'espace de table

Voici un excellent lien sur la façon de rattacher n'importe quel fichier .ibd à ibdata1 en cas d'ID d'espace de table incompatibles: http://www.chriscalender.com/?tag=innodb-error-tablespace-id-in- fichier . Après avoir lu ceci, vous devriez vous rendre compte immédiatement que la copie de fichiers .ibd est tout simplement folle.

Pour InnoDB, vous n'avez besoin que de quelque chose pour bouger

CREATE TABLE db2.mytable LIKE db1.mytable;
INSERT INTO db2.mytable SELECT * FROM db1.mytable;

pour faire une copie d'une table InnoDB.

Si vous le migrez vers un autre serveur de base de données, utilisez mysqldump.

En ce qui concerne le mélange de toutes les tables InnoDB de toutes les bases de données, je peux réellement voir la sagesse de le faire. Dans la société d'hébergement DB/Web de mon employeur, j'ai un client MySQL qui a une table dans une base de données dont les contraintes sont mappées à une autre table dans une autre base de données au sein de la même instance MySQL. Avec un référentiel de métadonnées commun, il rend possible la prise en charge transactionnelle et l'opérabilité MVCC sur plusieurs bases de données.

69
RolandoMySQLDBA

Vous pouvez basculer InnoDB pour stocker des tables par fichier en ajoutant innodb-file-per-table à votre cnf.

Innodb se soucie vraiment des pages de données au niveau de base. En fait, vous pouvez configurer InnoDB pour utiliser uniquement un périphérique de bloc brut sans système de fichiers quoi que ce soit! http://dev.mysql.com/doc/refman/5.5/en/innodb-raw-devices.html

Il y a des avantages à stocker des tables pour un fichier, comme pouvoir regagner plus facilement l'espace utilisé via optimiser.

Même avec des fichiers par table, vous ne pouvez pas simplement copier les fichiers ibd si facilement car InnoDB est transactionnel et stocke des informations sur son état dans les fichiers ibdata/log partagés globalement.

Cela ne veut pas dire que cela ne peut pas être fait. Si la table est hors ligne, vous pouvez supprimer/importer les espaces de table et copier les .idbs autour http://dev.mysql.com/doc/refman/5.5/en/innodb-multiple-tablespaces.html

14
atxdba

Il s'agit du comportement par défaut mais pas obligatoire. De Documents MySQL, Utilisation des tablespaces par table :

Par défaut, toutes les tables et tous les index InnoDB sont stockés dans l'espace disque logique système. Comme alternative, vous pouvez stocker chaque table InnoDB et ses index dans son propre fichier . Cette fonctionnalité est appelée "plusieurs espaces disque logiques" car chaque table créée lorsque ce paramètre est en vigueur possède son propre espace disque logique.

Quant à savoir pourquoi, la raison en est probablement les différentes architectures des deux moteurs (MyISAM et InnoDB). Par exemple, dans InnoDB, vous ne pouvez pas simplement copier le fichier .ibd dans une autre base de données ou installation. Explication (à partir de la même page):

Considérations de portabilité pour les fichiers .ibd

Vous ne pouvez pas déplacer librement les fichiers .ibd entre les répertoires de base de données comme vous pouvez le faire avec les fichiers de table MyISAM. La définition de table stockée dans l'espace de table partagé InnoDB inclut le nom de la base de données. Les ID de transaction et les numéros de séquence de journal stockés dans les fichiers d'espace disque logique diffèrent également entre les bases de données.

10
ypercubeᵀᴹ