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

Depuis que MySQL 5.6 a introduit DDL en ligne, la ALTER TABLEcommande peut éventuellement avoir soit ALGORITHM=INPLACEou ALGORITHM=COPYspécifié. La vue d'ensemble du DDL en ligne note que, par défaut, INPLACEest utilisé dans la mesure du possible, et implique (sans jamais le dire tout à fait) que l' INPLACEalgorithme est moins cher que COPYcelui.

Alors, quelle raison aurais-je à préciser ALGORITHM=COPYsur une ALTER TABLEdéclaration?

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

Il est important de comprendre que MySQL a introduit une nouvelle fonctionnalité - le traitement des DLL en ligne dans la version 5.6. Il n'a pas supprimé le traitement hors ligne. Il faut donc différencier ces 2 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 en choisir un "ancien" pour des raisons de compatibilité.

Quelques exemples (veuillez en suggérer plus):

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

2. ADD PRIMARY KEYLa clause in COPY modeconvertit silencieusement les NULLvaleurs par défaut pour ce type de données (0 pour INT, chaîne vide pour varchar), alors IN_PLACEqu'elle ne le fait pas.

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 l' ALTER INDEXopération, la table est donc en lecture seule ou entièrement verrouillée et il existe un processus qui lit la table statique pendant la reconstruction de l'index.

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

J'ai vu des choses comme ça (dans les drapeaux sql_mode, les my.cnfparamè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.

Dans les versions de MySQL qui prennent en charge le chiffrement de l'espace de table InnoDB, lorsque vous modifiez une table pour ajouter un chiffrement, la modification est effectuée en utilisant l'algorithme de copie par nécessité.