¿Por qué preferiría ALGORITHM = COPY a ALGORITHM = INPLACE?


16

Desde que MySQL 5.6 introdujo DDL en línea, el ALTER TABLEcomando opcionalmente puede tener uno ALGORITHM=INPLACEu otro ALGORITHM=COPY. La descripción general de DDL en línea señala que, de forma predeterminada, INPLACEse usa siempre que sea posible e implica (sin decirlo nunca) que el INPLACEalgoritmo es más barato que el anterior COPY.

Entonces, ¿qué razón tendría que especificar ALGORITHM=COPYen una ALTER TABLEdeclaración?


Si usa COPY, ¿qué sucede con los índices en la tabla? ¿Terminas con índices desfragmentados debido a una nueva tabla que se está creando y completando desde cero?
Dave Poole el

Si COPY se completa desde cero, aunque es una opción lenta, la tabla resultante podría funcionar mejor debido a los índices desfragmentados.
Dave Poole

@DavePoole Teoría de Niza, pero sospecho que está fuera de lugar, ya OPTIMIZE TABLEque (creo que tiene índices de desfragmentación como una gran parte de su propósito ) se utiliza a ALGORITHM=INPLACEpartir de MySQL 5.7.4. Así que creo que es el caso de que, sí, COPY hace índices de desfragmentación, pero también lo haceINPLACE (de alguna manera), anulando como una ventaja potencial de COPY.
Mark Amery

2
"Las tablas InnoDB creadas antes de MySQL 5.6 no son compatibles ALTER TABLE ... ALGORITHM=INPLACEcon las tablas que incluyen columnas temporales (DATE, DATETIME o TIMESTAMP) y no se han reconstruido usando ALTER TABLE ... ALGORITHM=COPY" ... Limitaciones de DDL en línea
JSapkota

Respuestas:


10

Sí, hay casos en los que puede especificar COPY, pero sería por otras razones además del rendimiento.

Es importante comprender que MySQL introdujo una nueva característica: el procesamiento de DLL en línea en la versión 5.6. No eliminó el procesamiento fuera de línea. Por lo tanto, es necesario diferenciar entre estos 2 modos:

  1. Algunas operaciones siguen funcionando solo en modo sin conexión. Consulte la Tabla 15.10, “ Resumen del estado en línea para operaciones DDL ” para obtener una lista de las operaciones DDL que pueden o no pueden realizarse en el lugar.

  2. Las operaciones en los modos en línea y fuera de línea tienen un comportamiento ligeramente diferente, por lo que puede elegir uno "antiguo" por razones de compatibilidad.

Algunos ejemplos (sugiera más):

  1. Las tablas InnoDB creadas antes de MySQL 5.6 no son compatibles ALTER TABLE ... ALGORITHM=INPLACEcon las tablas que incluyen columnas temporales ( DATE, DATETIMEo TIMESTAMP) y no se han reconstruido utilizando ALTER TABLE ... ALGORITHM=COPY. En este caso, una ALTER TABLE ... ALGORITHM=INPLACEoperación devuelve un error.

  2. ADD PRIMARY KEYLa cláusula in COPY modeconvierte silenciosamente NULLa valores predeterminados para ese tipo de datos (0 para INT, cadena vacía para varchar), mientras IN_PLACEque no hace eso.

Con la cláusula ALGORITHM = COPY, la operación tiene éxito a pesar de la presencia de valores NULL en las columnas de clave principal; los datos se cambian silenciosamente, lo que podría causar problemas.

Otra razón para preferir COPY:

Operaciones para las que especifica ALGORITHM = COPY o old_alter_table = 1, para forzar el comportamiento de copia de la tabla si es necesario para una compatibilidad con versiones anteriores precisa en escenarios especializados.

Aunque el manual de MySQL no habla sobre escenarios reales, puedes imaginar algunos. Por ejemplo, el desarrollador confió en que la tabla se bloqueó durante la ALTER INDEXoperación, por lo que la tabla es de solo lectura o está completamente bloqueada y hay un proceso que lee la tabla estática durante la reconstrucción del índice.


1
Creo que la gente también tiende a confundir ALGORITHM=INPLACEcon "esto es DDL en línea y no bloqueará la base de datos", cuando de hecho, realmente quieren usarlo LOCK=NONE.
Brendan Byrd

2

@Stoleg probablemente tenga la mejor respuesta, pero aquí hay otra. Es una suposición educada que los desarrolladores dejaron =COPYcomo una escotilla de escape en caso de que hubiera un error grave =INLINE. Esto permitiría a los usuarios continuar utilizando ALTERincluso si la nueva característica está rota.

He visto cosas como esta (en banderas sql_mode, my.cnfconfiguraciones, etc.) a lo largo de los años. La intención del nuevo lanzamiento es claramente mostrar la nueva y mejor característica.

Las banderas de optimización caen en esta categoría, pero hay aún más razones para aferrarse a las acciones anteriores: el Optimizador siempre "lo hará mal" a veces; Simplemente hay demasiadas posibilidades.


1
¿Por qué lo llamarías "trampilla de escape" en lugar de "compatibilidad con versiones anteriores"? Aunque puede que no haya mucha diferencia;)
Stoleg

1
Diría "compatibilidad con versiones anteriores" si necesito el mismo código para ejecutar en ambas versiones. Pero luego me preocuparía si la nueva versión reconocía la nueva sintaxis.
Rick James

-1

En las versiones de MySQL que admiten el cifrado de espacio de tabla InnoDB, cuando se modifica una tabla para agregar cifrado, la modificación se realiza utilizando el algoritmo de copia por necesidad.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.