# crear índice de ordenación
El estado de subproceso `creating sort index` indica que un subproceso está procesando una instrucción `SELECT` que requiere el uso de una tabla temporal interna para ordenar los datos.
**Topics**
+ [Versiones del motor admitidas](#ams-states.sort-index.context.supported)
+ [Contexto](#ams-states.sort-index.context)
+ [Causas probables del aumento de las esperas](#ams-states.sort-index.causes)
+ [Acciones](#ams-states.sort-index.actions)
## Versiones del motor admitidas
Esta información de estado de subproceso es compatible con las siguientes versiones:
+ Aurora MySQL versión 2, hasta la versión 2.09.2
## Contexto
El estado `creating sort index` aparece cuando una consulta con una cláusula `ORDER BY` o `GROUP BY` no puede utilizar un índice existente para realizar la operación. En este caso, MySQL necesita realizar una operación `filesort` más costosa. Esta operación se realiza normalmente en la memoria si el conjunto de resultados no es demasiado grande. De lo contrario, requiere crear un archivo en disco.
## Causas probables del aumento de las esperas
La apariencia de `creating sort index` no indica un problema. Si el rendimiento es deficiente y ve instancias frecuentes de `creating sort index`, la causa más probable es la lentitud de las consultas con los operadores `ORDER BY` o `GROUP BY`.
## Acciones
La directriz general consiste en buscar consultas con las cláusulas `ORDER BY` o `GROUP BY` asociadas a los aumentos del estado `creating sort index`. A continuación, compruebe si, al agregar un índice o aumentar el tamaño del búfer de ordenación, se resuelve el problema.
**Topics**
+ [Activar Performance Schema si no está activado](#ams-states.sort-index.actions.enable-pfs)
+ [Identificar las consultas problemáticas](#ams-states.sort-index.actions.identify)
+ [Examinar los planes de explicación para el uso de filesort](#ams-states.sort-index.actions.plan)
+ [Aumentar el tamaño del búfer de ordenación](#ams-states.sort-index.actions.increasebuffersize)
### Activar Performance Schema si no está activado
Información sobre rendimiento informa de los estados de subprocesos solo si los instrumentos de Performance Schema no están activados. Cuando los instrumentos de Performance Schema están activados, Información sobre rendimiento informa de los eventos de espera en su lugar. Los instrumentos de Performance Schema proporcionan información adicional y mejores herramientas para investigar posibles problemas de rendimiento. Por lo tanto, se recomienda activar Performance Schema. Para obtener más información, consulte [Descripción general de Performance Schema para Información de rendimiento en Aurora MySQL](USER_PerfInsights.EnableMySQL.md).
### Identificar las consultas problemáticas
Para identificar las consultas actuales que están provocando aumentos en el estado `creating sort index`, ejecute `show processlist` y compruebe si alguna de las consultas tiene `ORDER BY` o `GROUP BY`. Opcionalmente, ejecute `explain for connection N`, donde `N` es el ID de lista de procesos de la consulta con `filesort`.
Para identificar las consultas anteriores que están causando estos aumentos, active el registro de consultas lentas y busque las consultas con `ORDER BY`. Ejecute `EXPLAIN` en las consultas lentas y utilice filesort. Para obtener más información, consulte [Examinar los planes de explicación para el uso de filesort](#ams-states.sort-index.actions.plan).
### Examinar los planes de explicación para el uso de filesort
Identifique las instrucciones con las cláusulas `ORDER BY` o `GROUP BY` que dan lugar al estado `creating sort index`.
El siguiente ejemplo muestra cómo ejecutar `explain` en una consulta. La columna `Extra` muestra que esta consulta utiliza `filesort`.
```
mysql> explain select * from mytable order by c1 limit 10\G
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: mytable
partitions: NULL
type: ALL
possible_keys: NULL
key: NULL
key_len: NULL
ref: NULL
rows: 2064548
filtered: 100.00
Extra: Using filesort
1 row in set, 1 warning (0.01 sec)
```
El siguiente ejemplo muestra el resultado de ejecutar `EXPLAIN` en la misma consulta después de crear un índice en la columna `c1`.
```
mysql> alter table mytable add index (c1);
```
```
mysql> explain select * from mytable order by c1 limit 10\G
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: mytable
partitions: NULL
type: index
possible_keys: NULL
key: c1
key_len: 1023
ref: NULL
rows: 10
filtered: 100.00
Extra: Using index
1 row in set, 1 warning (0.01 sec)
```
Para obtener información sobre el uso de índices para la optimización del orden de clasificación, consulte [ORDER BY Optimization](https://dev.mysql.com/doc/refman/5.7/en/order-by-optimization.html) en la documentación de MySQL.
### Aumentar el tamaño del búfer de ordenación
Para ver si una consulta específica ha necesitado un proceso `filesort` que creó un archivo en disco, verifique el valor de la variable `sort_merge_passes` después de ejecutar la consulta. A continuación se muestra un ejemplo.
```
mysql> show session status like 'sort_merge_passes';
+-------------------+-------+
| Variable_name | Value |
+-------------------+-------+
| Sort_merge_passes | 0 |
+-------------------+-------+
1 row in set (0.01 sec)
--- run query
mysql> select * from mytable order by u limit 10;
--- run status again:
mysql> show session status like 'sort_merge_passes';
+-------------------+-------+
| Variable_name | Value |
+-------------------+-------+
| Sort_merge_passes | 0 |
+-------------------+-------+
1 row in set (0.01 sec)
```
Si el valor de `sort_merge_passes` es alto, considere la posibilidad de aumentar el tamaño del búfer de ordenación. Aplique el aumento en el nivel de la sesión, ya que aumentarlo globalmente puede incrementar significativamente la cantidad de RAM que utiliza MySQL. En el ejemplo siguiente se muestra cómo cambiar el tamaño del búfer de ordenación antes de ejecutar una consulta.
```
mysql> set session sort_buffer_size=10*1024*1024;
Query OK, 0 rows affected (0.00 sec)
-- run query
```