De rejoindre les tables InnoDB avec les tables MyISAM
Nous avons un ensemble de tables qui contiennent les meta données au niveau des organisations semblables, de l'organisation des utilisateurs, des services de l'organisation, etc. Tous ces tableaux sont va être lu lourd avec très peu d'opérations d'écriture. Aussi, les dimensions de la table serait assez petite (nombre maximal d'enregistrements seraient de l'ordre de 30K - 40K)
Un autre jeu de table de stocker des données OLTP comme le projet de loi de transactions, les actions de l'utilisateur, etc, qui vont être à la fois lire et écrire lourd. Ces tableaux serait assez énorme (environ 30 Millions d'enregistrements par table)
Pour la première série de tableaux, nous envisageons d'aller avec MyISAM et, pour les secondes avec le moteur InnoDb. Beaucoup de nos fonctions exigent également des JOINTURES sur des tables à partir de ces 2 jeux.
Existe-il des problèmes de performances dans de rejoindre les tables MyISAM avec les tables InnoDB? Aussi, y at-il d'autres questions (db sauvegardes, tuning etc) on pourrait dans ce genre de dessin?
Tout commentaire serait grandement apprécié.
Vous devez vous connecter pour publier un commentaire.
Ce qui saute immédiatement à moi est MyISAM.
ASPECT n ° 1 : Le REJOINDRE
Chaque fois qu'il a rejoint impliquant MyISAM et InnoDB, les tables InnoDB va finir par avoir au niveau de la table de verrouillage de comportement plutôt qu'au niveau de la ligne de verrouillage en raison de MyISAM implication dans la requête et MVCC ne peut pas être appliqué à la MyISAM données. MVCC ne peut pas être appliqué même à InnoDB dans certains cas.
ASPECT #2 : MyISAM la Participation de
À partir d'un autre point de vue, si toutes les tables MyISAM sont en train d'être mis à jour via Insertions, Mises à jour ou Suppressions, les tables MyISAM impliqués dans une requête de JOINTURE serait verrouillée de l'autre DB Connections et la requête de JOINTURE doit attendre jusqu'à ce que les tables MyISAM peut être lu. Malheureusement, si il y a un mélange de InnoDB et MyISAM dans la requête de JOINTURE, les tables InnoDB aurait à l'expérience d'un verrouillage par intermittence comme son MyISAM partenaires dans la requête de JOINTURE en raison de la tenue de l'écriture.
Gardez à l'esprit que MVCC vous permettra quand même de LIRE non VALIDÉES et la reproductibilité de LIRE les transactions à très bien fonctionner et permettre à certaines des vues de données disponibles pour d'autres opérations. Je ne peux pas en dire de même pour la LECTURE ENGAGÉE et SERIALIZABLE.
ASPECT #3 : Optimiseur de Requête
MySQL s'appuie sur l'indice de cardinalité pour déterminer une optimisation du plan d'EXPLIQUER. L'indice de la cardinalité est stable dans les tables MyISAM, jusqu'à ce que les Insertions, Mises à jour et des Suppressions arriver à la table, par lequel vous pourriez exécuter régulièrement
OPTIMIZE TABLEcontre les tables MyISAM. InnoDB indice de cardinalité n'est JAMAIS STABLE !!! Si vous exécutezSHOW INDEXES FROM *innodbtable*;, vous verrez l'indice de la cardinalité de changer à chaque fois que vous exécutez cette commande. C'est parce que InnoDB va faire des plongées dans l'indice pour estimer la cardinalité. Même si vous exécutezOPTIMIZE TABLEcontre une table InnoDB, qui ne défragmenter la table.OPTIMIZE TABLEsera exécutéANALYZE TABLEen interne pour générer des statistiques d'index sur la table. Qui fonctionne pour MyISAM. InnoDB l'ignore.Mon conseil pour vous est d'aller tous dehors et tout convertir InnoDB et optimiser vos réglages en conséquence.
MISE À JOUR 2012-12-18 15:56 HAE
Croyez le ou non, il est encore un billet ouvert sur InnoDB/MyISAM rejoindre lors d'un SELECT FOR UPDATE. Si vous avez bien lu, il résume la résolution comme suit : NE PAS le FAIRE !!!.
Je ne pense pas que la gestion des transactions de fonctionner correctement ou à tous depuis les tables MyISAM ne pas s'en occuper.