Problemas de uso elevado del disco

En esta página, se describen los problemas conocidos de uso elevado del disco y se ofrece ayuda para solucionar problemas.

Entre los problemas conocidos de uso elevado del disco, se incluyen los siguientes:

  • Uso elevado de archivos Temporary_files en MySQL 8.0 y versiones posteriores
  • Uso elevado de archivos Others en MySQL 8.0 y versiones anteriores.

El consumo de archivos temporales se clasifica en archivos tmp_data en las versiones anteriores a MySQL 8.0.

Métrica de desglose del almacenamiento de MySQL

La métrica principal que se usa para supervisar el uso detallado del disco es cloudsql.googleapis.com/database/disk/bytes_used_by_data_type. Esta métrica proporciona un desglose del uso del disco de la instancia por tipo de datos de la siguiente manera:

Tipo de datos Definición
Binlog Almacenamiento que usan los registros binarios de MySQL, esencial para la recuperación de un momento determinado y la replicación.
Cloudsql_mysql_audit_log Es el almacenamiento que usa el registro de auditoría de Cloud SQL MySQL.
Data Incluye los tablespaces primarios InnoDB (archivos .ibd) y el tablespace del sistema (ibdata1).
General_log Es el almacenamiento que usa el registro de consultas general.
General_tablespace Es el almacenamiento que usa el espacio de tabla del sistema InnoDB, que consta de los archivos ibdata*.
Last_sys_tablespace Es el almacenamiento utilizado por el tablespace más reciente.
Others Incluye archivos internos del sistema.
Redo_log Almacenamiento que consumen los registros de rehacer de InnoDB que se usan para la recuperación ante fallas.
Relaylog Es el almacenamiento que usan los registros de retransmisión en una instancia de réplica durante la replicación.
Slow_log Es el almacenamiento que usa el registro de consultas lentas si está habilitado y se almacena en el disco.
Temporary files Es el almacenamiento explícitamente rastreado para los archivos temporales creados por MySQL.
Temporary_space Es el almacenamiento que usan los archivos temporales del sistema operativo en el directorio /tmp.
Tmp_data Son los datos temporales que crea MySQL durante operaciones como la ordenación y la unión.
Undo_log Es el almacenamiento que usan los registros de deshacer.

Cómo ubicar archivos en las categorías Temporary_files y Others

Las consultas de larga duración (como las operaciones complejas de JOIN, ORDER BY o GROUP BY) crean archivos temporales grandes en el directorio de MySQL.

En el caso de las instancias de MySQL que usan versiones de mantenimiento lanzadas a partir de abril de 2026, estos archivos temporales se informan de forma explícita en la categoría Temporary_files.

En versiones anteriores, los archivos temporales se informan en la categoría Others.

Soluciona problemas de uso alto del disco

Para solucionar los problemas de uso elevado del disco causados por archivos temporales grandes, sigue estos pasos:

  1. Identifica las consultas activas de larga duración.
  2. Mitigación inmediata.
  3. Usa las Estadísticas de consultas.
  4. Realiza un análisis retrospectivo.
  5. Optimiza las consultas.
  6. Configura la supervisión y las alertas.

Identifica las consultas activas de larga duración

Los problemas de uso elevado del disco se deben, con mayor frecuencia, a consultas de larga duración (como operaciones complejas de JOIN, ORDER BY o GROUP BY) que crean archivos temporales masivos en el directorio de MySQL. Estos archivos temporales se clasifican en las categorías Temporary_files o Others.

Las instancias de MySQL con versiones de mantenimiento nuevas (versión r20260320.00_00 y posteriores) tienen la tabla INFORMATION_SCHEMA.CLOUDSQL_OPEN_TEMP_FILES, que muestra los archivos temporales creados por las consultas de larga duración y que MySQL desvincula (es decir, los archivos existen, pero no están vinculados al proceso de MySQL).

Usa la siguiente consulta para obtener la consulta activa de larga duración:

SELECT
otf.fd, otf.size, p.id, p.info, p.user
FROM
 INFORMATION_SCHEMA.CLOUDSQL_OPEN_TEMP_FILES otf
LEFT JOIN
performance_schema.processlist p
ON
otf.SESSION_ID = p.ID;

Resultado de muestra:

+----+------------+------+----------------------------------+------+
| fd | size       | id   | info                             | user |
+----+------------+------+----------------------------------+------+
| 39 | 1670750208 |    8 | select * from t1 order by rand() | root |
| 40 | 1670750208 |    8 | select * from t1 order by rand() | root |
+----+------------+------+----------------------------------+------+
2 rows in set (0.00 sec)

Para las instancias con versiones de mantenimiento r20260320.00_00 y anteriores, usa la siguiente consulta para obtener la consulta activa de larga duración:

SHOW FULL PROCESSLIST;

En el resultado, busca las operaciones que suelen usar archivos temporales de disco:

  • Operaciones JOIN grandes, en especial sin índices adecuados
  • Operaciones complejas de ORDER BY o GROUP BY en grandes conjuntos de resultados
  • Operaciones ALTER TABLE grandes

Mitigación inmediata

Si se identifica una consulta en ejecución como la fuente del consumo de disco durante la investigación, puedes finalizarla para liberar el espacio de archivos temporales asociado.

Para finalizar la consulta, ejecuta el siguiente comando:

KILL PROCESS_ID;

Reemplaza PROCESS_ID por el ID del proceso de la consulta:

  • En el caso de las versiones de mantenimiento r20260320 o posteriores, puedes recuperar el valor de PROCESS_ID a través de la columna SESSION_ID de la tabla INFORMATION_SCHEMA.CLOUDSQL_OPEN_TEMP_FILES.

  • En versiones anteriores (versión r20260117 o anterior) , puedes recuperar el valor de PROCESS_ID del resultado de la operación SHOW FULL PROCESSLIST.

Después de que finaliza una consulta responsable del consumo elevado de disco a través de archivos temporales, es posible que estos cambios tarden hasta 5 minutos en registrarse en las métricas de uso del disco.

Usar Estadísticas de consultas

Te recomendamos que uses las estadísticas de consultas para identificar y mejorar las consultas con un rendimiento lento.

Para obtener más información, consulta Usa las estadísticas de consultas para mejorar el rendimiento de las consultas.

Realiza un análisis retrospectivo

Cuando el aumento repentino del uso disminuya, puedes analizar los datos históricos para identificar la causa con lo siguiente:

  • Estadísticas de consultas Verifica si hay consultas que puedan haber creado archivos temporales grandes. Examina las consultas que se enumeran por resumen de consultas (incluidas métricas como el tiempo de ejecución promedio, la cantidad de consultas y el promedio de filas analizadas y devueltas).

  • Slow_log. Habilita Slow_log y establece long_query_time en un umbral adecuado. Este registro captura las consultas de larga duración para el análisis y la optimización.

  • General_log: Verifica General_log (si está habilitado) para las búsquedas registradas durante el período del incidente que tengan operaciones JOIN o SORT que puedan haber generado archivos temporales grandes. De lo contrario, puedes habilitar General_log y capturar la consulta en el siguiente evento de este tipo.

  • Métricas de Cloud Monitoring Revisa las siguientes métricas:

    • cloudsql.googleapis.com/database/mysql/tmp_disk_tables_created_count: Realiza un seguimiento de la cantidad de tablas temporales creadas en el disco, que suelen ser la causa de archivos grandes no vinculados.
    • cloudsql.googleapis.com/database/mysql/handler_operations_count: Realiza un seguimiento de la cantidad de operaciones que aumentan en ese momento.
    • cloudsql.googleapis.com/database/mysql/innodb/active_trx_total_time: Realiza un seguimiento de las transacciones activas durante un período más prolongado.

    Un aumento en estas métricas que coincide con el incremento repentino en el uso del disco sugiere que las consultas que generan tablas temporales grandes fueron la causa raíz.

  • Historial de transacciones Revisa las siguientes métricas:

    • cloudsql.googleapis.com/database/mysql/innodb/history_list_length metric: Una lista de historial larga puede deberse a transacciones de larga duración que bloquean la purga de los registros de deshacer, lo que también puede contribuir a problemas de uso del disco.
    • cloudsql.googleapis.com/database/mysql/innodb/active_trx_longest_time: Transacciones de larga duración durante el período de uso elevado del disco.

Optimiza las consultas

Una vez que el análisis de registros haya identificado las consultas específicas que provocan picos en las métricas, puedes optimizarlas o volver a escribirlas para minimizar la generación de archivos temporales extensos.

Para optimizar una consulta, puedes hacer lo siguiente:

  • Agrega los índices adecuados.
  • Refactoriza las operaciones complejas de unión o clasificación.

Para obtener más información, consulta Ajuste de consultas.

Configura la supervisión y las alertas

Para evitar futuros incidentes causados por el uso descontrolado del disco, en especial debido a los archivos temporales generados a partir de consultas de larga duración, implementa la supervisión y las alertas proactivas con Monitoring.

Puedes crear alertas para las métricas que indican un alto consumo de recursos o patrones de consultas que se sabe que generan archivos temporales grandes.

Nombre de la métrica Descripción Umbral de alerta recomendado
cloudsql.googleapis.com/database/disk/utilization Es el porcentaje del espacio en el disco asignado que se utiliza.

Esta métrica supervisa el uso general de la capacidad del disco.

 Más del 80% (sostenido durante 5 minutos)
cloudsql.googleapis.com/database/disk/bytes_used Cantidad total de bytes de espacio en disco que usa la instancia de base de datos.

Esta métrica hace un seguimiento del crecimiento absoluto del consumo de disco.

 Supervisar según la métrica database/disk/quota

Para obtener información sobre cómo configurar alertas y supervisar las métricas de Cloud SQL, consulta Descripción general de las alertas y Supervisa instancias de Cloud SQL.