Transferencia desde: http://ctripmysqldba.iteye.com/blog/1938150 (con modificaciones)
Al realizar operaciones DDL, como alterar tabla, MySQL a veces tiene una escena de espera para el bloqueo de metadatos de tabla en espera. Además, una vez que la operación de alterar la tabla TableA está atascada en el estado de espera de bloqueo de metadatos de la tabla, no se pueden realizar operaciones posteriores (incluida la lectura) en la tabla A, ya que también ingresarán al bloqueo de metadatos de la tabla en espera en la etapa de apertura de tablas Esperando la cola. Si dicha cola de espera de bloqueo aparece en la tabla principal del entorno de producción, tendrá consecuencias desastrosas.
La razón por la que alter table produce el bloqueo de metadatos de la tabla Waiting for table es realmente muy simple, generalmente los siguientes escenarios simples:
Escenario 1: cosas largas ejecutándose, bloqueando DDL y luego bloqueando todas las operaciones posteriores de la misma tabla
A través de la lista de procesos show, puede ver que hay operaciones en curso (incluida la lectura) en la Tabla A. En este momento, la instrucción alter table no puede obtener el bloqueo exclusivo de metadatos y esperará.
Esta es la situación más básica y no entra en conflicto con el ddl en línea en mysql 5.6. Durante la operación de la tabla alter (ver la figura a continuación), el bloqueo exclusivo de metadatos se adquiere en el paso posterior a la creación. Al proceder al proceso de alteración de la tabla (generalmente el paso más lento), leer y escribir en la tabla puede ser normal. Para continuar, este es el rendimiento de ddl en línea, y no bloqueará la escritura en todo el proceso de la tabla alternativa como antes. (Por supuesto, no todos los tipos de operaciones alternativas pueden estar en línea, puede consultar el manual oficial para obtener detalles: http://dev.mysql.com/doc/refman/5.6/en/innodb-create-index-overview.html )
Solución: elimine la sesión donde se encuentra el DDL.
Escenario 2: cosas no confirmadas, bloqueando DDL y luego bloqueando todas las operaciones posteriores de la misma tabla
No puedo ver ninguna operación en TableA a través de show processlist, pero en realidad hay transacciones no confirmadas, que se pueden ver en information_schema.innodb_trx . Antes de que se complete la transacción, el bloqueo en la Tabla A no se liberará y la tabla alternativa tampoco puede obtener el bloqueo exclusivo de metadatos.
Solución: Seleccione * de information_schema.innodb_trx \ G, encuentre el lado de la cosa no comprometida, luego mátela y deje que retroceda.
Escena tres:
No puedo ver ninguna operación en TableA a través de la lista de procesos show, y no hay transacciones en curso en information_schema.innodb_trx. Esto probablemente se deba a que en una transacción explícita, se realizó una operación fallida en la Tabla A (por ejemplo, se consultó un campo inexistente). En este momento, la transacción no se inició, pero el bloqueo adquirido por la declaración fallida sigue siendo válido y no se ha liberado . Las declaraciones fallidas se pueden encontrar en la tabla performance_schema.events_statements_current .
La descripción en el manual oficial es la siguiente:
Si el servidor adquiere bloqueos de metadatos para una declaración que es sintácticamente válida pero falla durante la ejecución, no libera los bloqueos antes. La liberación del bloqueo aún se aplaza hasta el final de la transacción porque la declaración fallida se escribe en el registro binario y los bloqueos protegen la coherencia del registro.
En otras palabras, a excepción de los errores de sintaxis, los bloqueos adquiridos por otras declaraciones de error no se liberarán hasta que la transacción se confirme o se revierta. porque la declaración fallida se escribe en el registro binario y los bloqueos protegen la consistencia del registro, pero es difícil entender la razón de este comportamiento, porque la declaración incorrecta no se registrará en el registro binario.
Método de procesamiento: encuentre su sid a través de performance_schema.events_statements_current , elimine la sesión. También puede eliminar la sesión donde se encuentra el DDL.
En resumen, la declaración de la tabla alternativa es muy peligrosa (de hecho, su peligro en realidad es causado por cosas no comprometidas o transacciones largas). Antes de la operación, es mejor confirmar que no hay operaciones en curso, no hay transacciones no comprometidas, No hay declaraciones de error en transacciones explícitas. Si hay tareas de mantenimiento para modificar la tabla, ejecutar cuando nadie está supervisando, es mejor establecer un tiempo de espera mediante lock_wait_timeout para evitar una larga espera para el bloqueo de metatatos.
