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

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?

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.

@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.

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.