Comandos FLUSH de MySQL: Referencia Completa para Administradores de Bases de Datos

La sentencia `FLUSH` de MySQL obliga al servidor a recargar cachés internas, cerrar y reabrir archivos de registro, restablecer contadores de estado y sincronizar el estado en memoria con las estructuras en disco, todo sin necesidad de reiniciar el servidor. Esto la convierte en una de las familias de comandos más críticas operacionalmente disponibles para un administrador de bases de datos.

Comprender cada variante, su alcance preciso y sus efectos secundarios no es un conocimiento opcional en entornos de producción. El uso incorrecto de `FLUSH TABLES WITH READ LOCK` en un sistema OLTP con alta carga, por ejemplo, puede causar bloqueos de escritura a nivel de aplicación que duren minutos. Esta referencia cubre todas las variantes significativas de `FLUSH`, incluyendo diferencias de comportamiento entre MySQL 5.7 y 8.x, implicaciones específicas de InnoDB, riesgos de replicación y requisitos de privilegios.

Por qué los comandos FLUSH son importantes en producción

El servidor MySQL mantiene numerosas estructuras en memoria para acelerar las operaciones: la caché de conexiones de host, cachés de tablas de permisos, descriptores de tablas abiertas, cachés de resultados de consultas y grupos de búferes del motor de almacenamiento. Estas cachés son autoritativas durante la ejecución. Cuando un administrador realiza cambios fuera de banda — editando directamente las tablas de permisos con `INSERT`/`UPDATE`, rotando archivos de registro a nivel del sistema operativo, o moviendo archivos `.ibd` — la vista en memoria del servidor queda desactualizada. Los comandos `FLUSH` reconcilian esa divergencia.

Categorías operacionales clave donde `FLUSH` es indispensable:

• Propagación de privilegios sin reiniciar `mysqld`
• Copias de seguridad en línea consistentes mediante instantáneas basadas en bloqueos
• Rotación de registros integrada con `logrotate` o scripts personalizados
• Restablecimiento de línea base de rendimiento antes de realizar benchmarks
• Invalidación de caché de hosts tras cambios en la topología de red
• Aplicación de durabilidad del motor de almacenamiento antes de ventanas de mantenimiento

Privilegios requeridos

La mayoría de las variantes de `FLUSH` requieren el privilegio `RELOAD`. `FLUSH TABLES WITH READ LOCK` requiere adicionalmente `LOCK TABLES`. En MySQL 8.0+, se introdujeron privilegios dinámicos de grano fino (`FLUSH_OPTIMIZER_COSTS`, `FLUSH_STATUS`, `FLUSH_TABLES`, `FLUSH_USER_RESOURCES`), que permiten un control de acceso más granular sin necesidad de otorgar el amplio privilegio `RELOAD`. Aplique siempre el principio de mínimo privilegio al asignarlos a cuentas de aplicación o monitoreo.

Referencia completa: comandos FLUSH de MySQL

1. FLUSH PRIVILEGES

“`sql

FLUSH PRIVILEGES;

“`

Este comando recarga las tablas de permisos en memoria desde la base de datos del sistema `mysql` (`mysql.user`, `mysql.db`, `mysql.tables_priv`, `mysql.columns_priv`, `mysql.procs_priv`). El servidor lee estas tablas al iniciarse y las almacena en caché. Cualquier DML directo (`INSERT`, `UPDATE`, `DELETE`) sobre esas tablas omite el mecanismo normal de `GRANT`/`REVOKE`, dejando la caché desactualizada hasta que se ejecute `FLUSH PRIVILEGES`.

Cuándo usarlo:

• Después de editar manualmente las tablas de permisos con SQL directo en lugar de sentencias `GRANT`/`REVOKE`
• Después de importar un mysqldump que incluye inserciones directas en `mysql.user`
• Después de restaurar una copia de seguridad parcial del esquema `mysql`

Matiz crítico: Cuando se usan las sentencias `GRANT`, `REVOKE`, `CREATE USER` o `DROP USER`, MySQL recarga automáticamente las tablas de permisos. `FLUSH PRIVILEGES` solo es necesario cuando se omiten completamente esas sentencias. Ejecutarlo innecesariamente es inofensivo, pero añade un breve bloqueo sobre la caché de tablas de permisos.

Nota sobre replicación: `FLUSH PRIVILEGES` se escribe en el registro binario y se replica a las réplicas de forma predeterminada. Este es generalmente el comportamiento deseado al gestionar usuarios en una topología de replicación.

2. FLUSH TABLES

“`sql

FLUSH TABLES;

FLUSH TABLES tbl1, tbl2;

“`

Este comando cierra todos los descriptores de archivos de tabla actualmente abiertos y los elimina de la caché de definición de tablas (TDC). En el siguiente acceso, MySQL reabre los archivos de tabla desde el disco. Esto es esencial después de cualquier manipulación de archivos fuera de banda.

Cuándo usarlo:

• Después de copiar o reemplazar archivos `.frm`, `.ibd` o `.MYD`/`.MYI` a nivel del sistema operativo
• Para liberar memoria de la caché de tablas en servidores con un valor `table_open_cache` muy grande
• Como requisito previo antes de usar `IMPORT TABLESPACE` en operaciones de tablespace transportable de InnoDB

Consideración de rendimiento: En un servidor con miles de tablas abiertas, `FLUSH TABLES` adquiere brevemente un bloqueo global. En sistemas de alta concurrencia, esto puede causar un pico de latencia notable. Prefiera la forma específica por tabla (`FLUSH TABLES tbl1, tbl2`) para minimizar el impacto.

3. FLUSH TABLES WITH READ LOCK (FTWRL)

“`sql

FLUSH TABLES WITH READ LOCK;

— perform backup operations

UNLOCK TABLES;

“`

Esta es una de las variantes de `FLUSH` más potentes y potencialmente disruptivas. Cierra todas las tablas abiertas, vacía la caché de consultas y adquiere un bloqueo de lectura global que impide cualquier operación de escritura en todas las bases de datos. El bloqueo persiste hasta que se emite `UNLOCK TABLES` o finaliza la sesión.

Cuándo usarlo:

• Antes de realizar una copia de seguridad física con herramientas como `mysqldump –single-transaction` (para bases de datos exclusivamente InnoDB, esto no es necesario — véase más abajo)
• Antes de usar `mysqlpump` o `xtrabackup` en entornos que no sean InnoDB
• Para crear una instantánea consistente en un punto en el tiempo en motores de almacenamiento mixtos (InnoDB + MyISAM)

Trampa crítica — bases de datos exclusivamente InnoDB: Para bases de datos que usan exclusivamente tablas InnoDB, `FTWRL` casi nunca es necesario. `mysqldump –single-transaction` abre una transacción de lectura repetible que proporciona una instantánea consistente sin bloquear las escrituras. Usar `FTWRL` en este escenario provoca bloqueos de escritura innecesarios.

Riesgo de replicación: Si `FTWRL` se ejecuta en una réplica, bloquea el hilo aplicador SQL, lo que provoca que el retraso de replicación se acumule durante la duración del bloqueo. Monitoree siempre `Seconds_Behind_Master` después de liberar el bloqueo.

Interacción con bloqueos de metadatos: En MySQL 5.7+, `FTWRL` espera a que todas las transacciones activas se completen antes de adquirir el bloqueo global. En un servidor con carga alta y transacciones de larga duración, esta espera puede ser indefinida. Use `SHOW PROCESSLIST` para identificar las transacciones bloqueantes antes de ejecutar `FTWRL`.

4. FLUSH HOSTS

“`sql

FLUSH HOSTS;

“`

MySQL mantiene una caché de hosts que registra el historial de intentos de conexión, incluidos los recuentos de autenticaciones fallidas. Cuando un host acumula más de `max_connect_errors` conexiones fallidas consecutivas, MySQL bloquea todas las conexiones posteriores desde ese host hasta que se borre la entrada de la caché.

Cuándo usarlo:

• Cuando un host cliente legítimo está bloqueado por haber superado `max_connect_errors`
• Después de resolver un problema de red que causó fallos repetidos en conexiones TCP
• Después de cambiar registros DNS que afectan la forma en que el servidor resuelve los nombres de host de los clientes

Alternativa en MySQL 8.0: En MySQL 8.0+, también puede truncar directamente la tabla de caché de hosts:

“`sql

TRUNCATE TABLE performance_schema.host_cache;

“`

Esto logra el mismo resultado y es más transparente en scripts automatizados.

Configuración proactiva: En lugar de depender de `FLUSH HOSTS` de forma reactiva, establezca `max_connect_errors` en un valor más alto (p. ej., `10000`) o configure `host_cache_size = 0` para deshabilitar completamente la caché de hosts en redes internas de confianza.

5. FLUSH STATUS

“`sql

FLUSH STATUS;

“`

Restablece la mayoría de las variables de estado de sesión y globales a cero. Esto incluye contadores como `Com_select`, `Handler_read_rows`, `Innodb_buffer_pool_reads`, `Threads_connected` y cientos de otros expuestos a través de `SHOW STATUS` o `performance_schema`.

Cuándo usarlo:

• Inmediatamente antes de un benchmark controlado para establecer una línea base de medición limpia
• Después de un cambio de configuración (p. ej., ajustar `innodb_buffer_pool_size`) para aislar el efecto en las métricas de E/S
• Al crear scripts de pruebas de regresión de rendimiento que comparan deltas de contadores antes/después

Limitación importante: `FLUSH STATUS` no restablece todos los contadores. Variables como `Uptime`, `Uptime_since_flush_status` y ciertas métricas internas de InnoDB no se ven afectadas. Para un monitoreo exhaustivo, use directamente las tablas `performance_schema`, que ofrecen granularidad por hilo y por evento que `FLUSH STATUS` no puede proporcionar.

6. FLUSH LOGS

“`sql

FLUSH LOGS;

FLUSH BINARY LOGS;

FLUSH ERROR LOGS;

FLUSH GENERAL LOGS;

FLUSH SLOW LOGS;

FLUSH RELAY LOGS;

“`

`FLUSH LOGS` cierra y reabre todos los archivos de registro del servidor. MySQL 5.7.2+ introdujo la posibilidad de vaciar tipos de registro específicos de forma individual, lo cual es mucho más preferible en producción.

Cuándo usarlo:

• Como parte de un script post-rotate de `logrotate` para indicar a MySQL que abra un nuevo archivo de registro después de que el anterior haya sido rotado
• Para forzar un nuevo archivo de registro binario (equivalente a `FLUSH BINARY LOGS`), lo que incrementa el número de secuencia del registro binario
• Antes de archivar registros antiguos para garantizar que todas las escrituras pendientes se vacíen al disco

Detalles del registro binario: `FLUSH BINARY LOGS` crea un nuevo archivo de registro binario y escribe un `Rotate_event` en el archivo anterior. Esta es la forma correcta de segmentar registros binarios para el archivado de recuperación en un punto en el tiempo (PITR). El archivo de registro binario actual y su posición pueden confirmarse con `SHOW MASTER STATUS` (MySQL 5.7) o `SHOW BINARY LOG STATUS` (MySQL 8.4+).

Ejemplo de integración con logrotate:

“`bash

/etc/logrotate.d/mysql

/var/log/mysql/mysql-slow.log {

daily

rotate 7

missingok

compress

postrotate

mysqladmin -u root -p flush-logs

endscript

}

“`

7. FLUSH QUERY CACHE

“`sql

FLUSH QUERY CACHE;

RESET QUERY CACHE;

“`

Advertencia de obsolescencia: La caché de consultas de MySQL fue declarada obsoleta en MySQL 5.7.20 y eliminada completamente en MySQL 8.0. Si está ejecutando MySQL 8.0 o posterior, este comando no existe.

Para entornos MySQL 5.6/5.7 donde la caché de consultas sigue activa:

• `FLUSH QUERY CACHE` desfragmenta la memoria de la caché de consultas sin eliminar los resultados almacenados
• `RESET QUERY CACHE` elimina completamente todos los resultados de consultas almacenados en caché

Cuándo usarlo (solo MySQL 5.6/5.7):

• Después de una modificación masiva de datos por lotes que invalida una parte significativa de los resultados almacenados en caché
• Cuando `Qcache_free_blocks` es alto en relación con `Qcache_total_blocks`, lo que indica fragmentación
• Antes de deshabilitar la caché de consultas (`SET GLOBAL query_cache_size = 0`) para liberar memoria de forma limpia

Alternativa moderna: En MySQL 8.0+, use el calentamiento del grupo de búferes de InnoDB (`innodb_buffer_pool_dump_at_shutdown`, `innodb_buffer_pool_load_at_startup`) y `performance_schema` para el análisis a nivel de consulta.

8. FLUSH USER_RESOURCES

“`sql

FLUSH USER_RESOURCES;

“`

Restablece los contadores de recursos por usuario rastreados por la limitación de velocidad integrada de MySQL. Estos contadores aplican los límites definidos en las sentencias `CREATE USER` o `GRANT`:

• `MAX_QUERIES_PER_HOUR`
• `MAX_UPDATES_PER_HOUR`
• `MAX_CONNECTIONS_PER_HOUR`
• `MAX_USER_CONNECTIONS`

Cuándo usarlo:

• Cuando un usuario ha agotado su cuota de consultas por hora y necesita que se le restaure el acceso inmediatamente antes de que el contador se restablezca de forma natural al inicio de la siguiente hora
• Después de aumentar los límites de recursos de un usuario y querer que los nuevos límites surtan efecto de inmediato
• Durante el desarrollo y las pruebas para restablecer cuotas entre ejecuciones de prueba

Nota: Este comando restablece los contadores de todos los usuarios simultáneamente. No existe granularidad por usuario a nivel de `FLUSH`. Si necesita restablecer los contadores de un único usuario, la única opción es modificar su cuenta con `ALTER USER` y luego emitir `FLUSH USER_RESOURCES`.

9. FLUSH ENGINE LOGS

“`sql

FLUSH ENGINE LOGS;

“`

Obliga a todos los motores de almacenamiento a vaciar sus búferes de escritura pendientes en sus respectivos archivos de registro. Para InnoDB, esto significa vaciar el búfer de redo log (`innodb_log_buffer_size`) en los archivos de redo log de InnoDB en disco.

Cuándo usarlo:

• Antes de realizar una copia de seguridad en frío de los archivos de datos de InnoDB para garantizar la consistencia del redo log
• Durante la resolución de problemas del motor de almacenamiento para descartar inconsistencias de datos relacionadas con el búfer
• Como parte de una lista de verificación previa al mantenimiento antes de detener el servicio MySQL

Contexto de durabilidad de InnoDB: La configuración `innodb_flush_log_at_trx_commit` de InnoDB controla con qué agresividad se vacía el redo log en cada confirmación de transacción. `FLUSH ENGINE LOGS` es una anulación manual que fuerza un vaciado independientemente de esa configuración. Esto es útil en escenarios donde se necesita un punto de control de durabilidad garantizado sin confirmar una transacción.

10. FLUSH DES_KEY_FILE

“`sql

FLUSH DES_KEY_FILE;

“`

Recarga el archivo de clave de cifrado DES especificado por la opción de inicio del servidor `–des-key-file`. Este archivo de clave era utilizado por las funciones `DES_ENCRYPT()` y `DES_DECRYPT()`.

Advertencia de obsolescencia: Las funciones `DES_ENCRYPT()` y `DES_DECRYPT()` fueron declaradas obsoletas en MySQL 5.7.6 y eliminadas en MySQL 8.0. Por lo tanto, este comando solo es relevante en instalaciones heredadas de MySQL 5.6/5.7.

Alternativa moderna de cifrado: Use el cifrado nativo de datos en reposo de MySQL (cifrado de tablespace InnoDB mediante `ALTER TABLE … ENCRYPTION='Y'`) combinado con los plugins MySQL Keyring (`keyring_file`, `keyring_okv`, `keyring_aws`) para los requisitos de cifrado en producción.

Tabla comparativa de comandos FLUSH

Replicación y FLUSH: qué se replica

No todos los comandos `FLUSH` se replican en los servidores réplica. Comprender esta distinción es fundamental en topologías de alta disponibilidad y replicación:

Replicados de forma predeterminada:

• `FLUSH PRIVILEGES`
• `FLUSH LOGS` (escrito como `Rotate_event` en el registro binario)
• `FLUSH USER_RESOURCES`

No replicados (locales a la sesión o excluidos explícitamente):

• `FLUSH TABLES WITH READ LOCK` — nunca se escribe en el registro binario
• `FLUSH STATUS` — afecta solo a los contadores del servidor local
• `FLUSH HOSTS` — solo la caché de hosts local
• `FLUSH ENGINE LOGS` — solo el estado del motor local

Para evitar que un comando `FLUSH` específico se replique incluso cuando normalmente lo haría, use el modificador `LOCAL` o `NO_WRITE_TO_BINLOG`:

“`sql

FLUSH NO_WRITE_TO_BINLOG PRIVILEGES;

FLUSH LOCAL PRIVILEGES; — equivalent shorthand

“`

Esto es útil cuando se gestionan privilegios de forma independiente en una réplica (p. ej., añadiendo usuarios de monitoreo que no deben existir en el primario).

Automatización de operaciones FLUSH con mysqladmin

Muchas operaciones de `FLUSH` pueden activarse desde la shell sin abrir una sesión de cliente MySQL, lo cual es útil en trabajos cron y scripts de mantenimiento:

“`bash

Flush binary logs

mysqladmin -u root -p flush-logs

Flush privileges

mysqladmin -u root -p flush-privileges

Flush host cache

mysqladmin -u root -p flush-hosts

Flush status counters

mysqladmin -u root -p flush-status

“`

En entornos de producción, almacene las credenciales en `~/.my.cnf` con `chmod 600` en lugar de pasar `-p` de forma interactiva, o use el mecanismo `–login-path` de MySQL con `mysql_config_editor`.

Consideraciones sobre el entorno de alojamiento

La capacidad de ejecutar comandos `FLUSH` depende en gran medida del entorno de alojamiento y del nivel de acceso a la base de datos otorgado. En un plan de VPS Hosting, normalmente se tiene acceso root completo a la instancia MySQL, lo que significa que puede ejecutar cualquier variante de `FLUSH`, modificar `my.cnf` y gestionar la rotación de registros directamente. Este es el entorno mínimo recomendado para cualquier trabajo serio de administración de bases de datos.

En el Alojamiento Web Compartido, el acceso a la base de datos suele estar restringido a un usuario sin privilegios que carece del privilegio `RELOAD`, lo que hace que la mayoría de los comandos `FLUSH` no estén disponibles. Si su aplicación requiere gestión de privilegios, control de rotación de registros o instantáneas consistentes para copias de seguridad, un entorno compartido será un bloqueador absoluto.

Para cargas de trabajo de bases de datos de alto rendimiento — especialmente aquellas que implican operaciones frecuentes de `FLUSH ENGINE LOGS` o grandes grupos de búferes de InnoDB — los Servidores Dedicados proporcionan el rendimiento de E/S y el ancho de banda de memoria necesarios para que estas operaciones no sean disruptivas. Un `FLUSH TABLES WITH READ LOCK` en un servidor con 256 GB de datos en el grupo de búferes tarda considerablemente más que en un servidor con almacenamiento NVMe rápido y canales de E/S dedicados.

Si gestiona una instancia MySQL junto con un panel de control web, el VPS con cPanel proporciona un entorno gestionado donde algunas operaciones de `FLUSH` (especialmente la rotación de registros y las recargas de privilegios) son gestionadas automáticamente por la capa de administración de bases de datos del panel de control, reduciendo la necesidad de intervención manual.

Para aplicaciones respaldadas por bases de datos que requieren un ecosistema completo de panel de control, revisar los Paneles de Control VPS disponibles le ayudará a identificar qué panel se integra mejor con su flujo de trabajo de administración de MySQL.

Lista de verificación de puntos clave

Use esta matriz de decisión antes de ejecutar cualquier comando `FLUSH` en producción:

• Antes de `FLUSH TABLES WITH READ LOCK`: Confirme que no hay transacciones de larga duración activas (`SHOW PROCESSLIST`). Verifique si su base de datos es exclusivamente InnoDB — si es así, use `–single-transaction` en su lugar.
• Antes de `FLUSH PRIVILEGES`: Confirme que está usando DML directo en las tablas de permisos. Si usó `GRANT`/`REVOKE`, este comando es redundante.
• Antes de `FLUSH LOGS`: Asegúrese de que su script de rotación de registros ya haya movido/renombrado el archivo de registro antiguo antes de indicar a MySQL que lo reabra.
• Antes de `FLUSH HOSTS`: Identifique primero la causa raíz de los fallos de conexión. Vaciar la caché de hosts sin solucionar el problema subyacente hará que el host vuelva a ser bloqueado.
• En MySQL 8.0+: Elimine cualquier llamada a `FLUSH QUERY CACHE` o `FLUSH DES_KEY_FILE` de los scripts — estos comandos no existen y causarán errores.
• En topologías de replicación: Use `FLUSH LOCAL` o `FLUSH NO_WRITE_TO_BINLOG` cuando la operación no deba propagarse a las réplicas.
• Para automatización: Use comandos `mysqladmin flush-*` en scripts en lugar de abrir sesiones completas del cliente MySQL.
• Auditoría de privilegios: Prefiera los privilegios dinámicos de MySQL 8.0 (`FLUSH_STATUS`, `FLUSH_TABLES`, etc.) sobre el amplio privilegio `RELOAD` para cuentas de monitoreo y copia de seguridad.

Preguntas frecuentes

¿Es necesario ejecutar FLUSH PRIVILEGES después de cada sentencia GRANT o REVOKE?

No. `GRANT`, `REVOKE`, `CREATE USER` y `DROP USER` recargan automáticamente las tablas de permisos en memoria. `FLUSH PRIVILEGES` solo es necesario después de modificaciones DML directas en las tablas del sistema `mysql` (p. ej., `UPDATE mysql.user SET …`).

¿Puede FLUSH TABLES WITH READ LOCK causar tiempo de inactividad en la aplicación?

Sí. Adquiere un bloqueo de escritura global que bloquea todas las operaciones `INSERT`, `UPDATE`, `DELETE` y DDL en todas las bases de datos del servidor. En un sistema OLTP con alta carga, incluso unos pocos segundos de `FTWRL` pueden agotar los grupos de conexiones y causar errores en cascada en la aplicación. Para bases de datos exclusivamente InnoDB, use `mysqldump –single-transaction` para evitar esto por completo.

¿Es FLUSH STATUS equivalente a reiniciar el servidor MySQL para fines de benchmark?

No. `FLUSH STATUS` restablece la mayoría de los contadores de estado, pero no borra el grupo de búferes de InnoDB, no restablece los estados de conexión ni afecta a las estadísticas acumuladas de `performance_schema`. Para un benchmark con una pizarra completamente en blanco, un reinicio del servidor combinado con el vaciado del grupo de búferes es más preciso, aunque impracticable en producción.

¿Por qué FLUSH HOSTS no aparece como comando independiente en algunas documentaciones de MySQL 8.0?

`FLUSH HOSTS` sigue funcionando en MySQL 8.0, pero el método preferido es `TRUNCATE TABLE performance_schema.host_cache`, que es más explícito y puede ejecutarse sin el privilegio `RELOAD` si el usuario tiene `DELETE` sobre `performance_schema`. Ambos logran el mismo resultado.

¿Qué ocurre si se ejecuta FLUSH ENGINE LOGS durante una carga de escritura máxima en InnoDB?

Fuerza un vaciado sincrónico del búfer de registro de InnoDB al disco, lo que puede causar una breve interrupción de escritura si los archivos de redo log están en almacenamiento lento. En servidores respaldados por NVMe, el impacto suele ser de menos de un milisegundo. En discos magnéticos o almacenamiento SAN con alta carga, puede causar picos de latencia notables. Programe esta operación durante ventanas de bajo tráfico cuando sea posible.