# La base de datos está creando tablas temporales en el disco
El uso reciente de la tabla temporal en el disco ha aumentado de forma significativa hasta el *porcentaje*. La base de datos está creando alrededor de *número* tablas temporales por segundo. Esto podría afectar al rendimiento y aumentar las operaciones de disco en *db-instance*.
**Topics**
+ [Versiones del motor admitidas](#proactive-insights.temp-tables.context.supported)
+ [Contexto](#proactive-insights.temp-tables.context)
+ [Causas probables de este problema](#proactive-insights.temp-tables.causes)
+ [Acciones](#proactive-insights.temp-tables.actions)
+ [Métricas relevantes](#proactive-insights.temp-tables.metrics)
## Versiones del motor admitidas
Esta información es compatible con todas las versiones de Aurora MySQL.
## Contexto
A veces es necesario que el servidor MySQL cree una tabla temporal interna mientras procesa una consulta. Aurora MySQL puede contener una tabla temporal interna en la memoria, donde puede procesarla TempTable o el motor de almacenamiento MEMORY, o bien InnoDB puede almacenarla en disco. Para obtener más información, consulte [Internal Temporary Table Use in MySQL](https://dev.mysql.com/doc/refman/5.6/en/internal-temporary-tables.html) (Uso de tablas temporales internas en MySQL) en *MySQL Reference Manual* (Manual de referencia de MySQL).
## Causas probables de este problema
El aumento de las tablas temporales en disco indica el uso de consultas complejas. Si la memoria configurada no es suficiente para almacenar tablas temporales en la memoria, Aurora MySQL crea las tablas en el disco. Esto puede afectar al rendimiento y aumentar las operaciones en disco.
## Acciones
Recomendamos diferentes acciones en función de las causas.
+ En Aurora MySQL versión 3, le recomendamos que utilice el motor de almacenamiento TempTable.
+ Optimice sus consultas para devolver menos datos. Para ello, seleccione solo las columnas necesarias.
Si activa el esquema de rendimiento con todos los instrumentos `statement` habilitados y cronometrados, puede realizar consultas a `SYS.statements_with_temp_tables` para recuperar la lista de consultas que utilizan tablas temporales. Para obtener más información, consulte [Prerequisites for Using the sys Schema](https://dev.mysql.com/doc/refman/8.0/en/sys-schema-prerequisites.html) (Requisitos previos para utilizar el esquema sys) en la documentación de MySQL.
+ Considere la posibilidad de indexar las columnas que participan en las operaciones de clasificación y agrupación.
+ Reescriba sus consultas para evitar columnas `BLOB` y `TEXT`. Estas columnas siempre usan el disco.
+ Ajuste los siguientes parámetros de la base de datos: `tmp_table_size` y `max_heap_table_size`.
El valor predeterminado para este parámetro es 16 MiB. Cuando se utiliza el motor de almacenamiento MEMORY para tablas temporales en memoria, su tamaño máximo se define mediante el valor `tmp_table_size` o `max_heap_table_size`, el que sea menor. Cuando se alcanza este tamaño máximo, MySQL convierte automáticamente la tabla temporal interna en memoria en una tabla temporal interna en disco de InnoDB. Para obtener más información, consulte [Use the TempTable storage engine on Amazon RDS for MySQL and Amazon Aurora MySQL](https://aws.amazon.com/blogs/database/use-the-temptable-storage-engine-on-amazon-rds-for-mysql-and-amazon-aurora-mysql/) (Utilice el motor de almacenamiento TempTable en Amazon RDS para MySQL y Amazon Aurora MySQL).
**nota**
Al crear tablas MEMORY de forma explícita con CREATE TABLE, solo la variable `max_heap_table_size` determina el tamaño al que puede crecer una tabla. Tampoco hay ninguna conversión a un formato en disco.
## Métricas relevantes
Las siguientes métricas de Información sobre el rendimiento están relacionadas con esta información:
+ Created\$1tmp\$1disk\$1tables
+ Created\$1tmp\$1tables
Para obtener más información, consulte [Created\$1tmp\$1disk\$1tables](https://dev.mysql.com/doc/refman/8.0/en/server-status-variables.html#statvar_Created_tmp_disk_tables) en la documentación de MySQL.