web-dev-qa-db-fra.com

Pourquoi préférerais-je jamais ALGORITHM = COPY à ALGORITHM = INPLACE?

Depuis que MySQL 5.6 a introduit le DDL en ligne, le ALTER TABLE la commande peut éventuellement avoir soit ALGORITHM=INPLACE ou ALGORITHM=COPY spécifié. aperçu du DDL en ligne note que, par défaut, INPLACE est utilisé dans la mesure du possible et implique ( sans jamais le préciser) que l'algorithme INPLACE est moins cher que celui COPY.

Alors, quelle raison aurais-je à spécifier ALGORITHM=COPY sur un ALTER TABLE déclaration?

mysqlalter-tableddlonline-operations
19
Mark Amery

Oui, il y a des cas où vous pouvez spécifier COPY, mais ce serait pour d'autres raisons que les performances.

Il est important de comprendre que MySQL a introduit une nouvelle fonctionnalité - Traitement en ligne DLL dans la version 5.6. Il n'a pas supprimé le traitement hors ligne. Il est donc nécessaire de différencier ces deux modes:

  1. Certaines opérations ne fonctionnent toujours qu'en mode hors ligne. Voir Tableau 15.10, " Résumé de l'état en ligne des opérations DDL " pour une liste des opérations DDL qui peuvent ou ne peuvent pas être effectuées sur place.

  2. Les opérations dans les modes En ligne et Hors ligne ont un comportement légèrement différent, vous pouvez donc choisir "ancien" pour des raisons de compatibilité.

Quelques exemples (veuillez en suggérer davantage):

  1. Les tables InnoDB créées avant MySQL 5.6 ne prennent pas en charge ALTER TABLE ... ALGORITHM=INPLACE pour les tables qui incluent des colonnes temporelles (DATE, DATETIME ou TIMESTAMP) et qui n'ont pas été reconstruites à l'aide de ALTER TABLE ... ALGORITHM=COPY. Dans ce cas, un ALTER TABLE ... ALGORITHM=INPLACE l'opération renvoie une erreur.

  2. ADD PRIMARY KEY clause dans COPY mode convertit silencieusement NULL en valeurs par défaut pour ce type de données (0 pour INT, chaîne vide pour varchar), tandis que IN_PLACE ne fait pas cela.

Avec la clause ALGORITHM = COPY, l'opération réussit malgré la présence de valeurs NULL dans les colonnes de clé primaire; les données sont modifiées en silence, ce qui pourrait provoquer des problèmes.

Une autre raison de préférer COPY:

Opérations pour lesquelles vous spécifiez ALGORITHM = COPY ou old_alter_table = 1, pour forcer le comportement de copie de table si nécessaire pour une rétrocompatibilité précise dans des scénarios spécialisés.

Bien que le manuel MySQL ne parle pas de scénarios réels, vous pouvez en imaginer certains. Par exemple. le développeur s'est appuyé sur le verrouillage de la table pendant ALTER INDEX opération pour que la table soit en lecture seule ou entièrement verrouillée et qu'il existe un processus qui lit la table statique pendant la reconstruction de l'index.

13
Stoleg

@Stoleg a probablement la meilleure réponse, mais en voici une autre. C'est une supposition éclairée que les développeurs ont quitté =COPY dans comme une trappe d'échappement au cas où il y aurait un bug sérieux dans =INLINE. Cela permettrait aux utilisateurs de continuer à utiliser ALTER même si la nouvelle fonctionnalité est interrompue.

J'ai vu des choses comme ça (dans les drapeaux, sql_mode, my.cnf paramètres, etc.) au fil des ans. L'intention de la nouvelle version est clairement de faire ressortir la nouvelle fonctionnalité, meilleure.

Les drapeaux d'optimisation entrent dans cette catégorie, mais il y a encore plus de raisons de s'accrocher aux actions précédentes - l'Optimizer "fera toujours mal" parfois; il y a tout simplement trop de possibilités.

2
Rick James