MySQL
Consejos de rendimiento Mysql

Seleccione la optimización de la declaración

A continuación hay algunos consejos para recordar mientras escribimos una consulta de selección en MySQL que puede ayudarnos y reducir nuestro tiempo de consulta:

1. Siempre que usemos en una tabla grande, debemos asegurarnos de que la columna en la cláusula donde está indexada o no. Ej .: - Seleccione * del empleado donde id_usuario> 2000. id_usuario si está indexado y luego acelerará la evaluación de la consulta. Los índices también son muy importantes durante las combinaciones y las claves externas.

2. Cuando necesite la sección más pequeña de contenido en lugar de recuperar datos completos de la tabla, intente usar el límite. En lugar de escribir Ex: - Seleccione * del empleado. Si solo necesita los primeros 20 empleados de lakhs, simplemente use el límite Ej .: - Seleccione * del límite de empleados 20.

3. También puede optimizar su consulta proporcionando el nombre de columna que desea en el conjunto de resultados. En lugar de escribir Ex: - Seleccione * del empleado. Solo mencione el nombre de la columna de la que necesita datos si su tabla tiene mucha columna y desea tener datos para algunos de ellos. Ej: - Seleccione id, nombre del empleado.

4. Columna de índice si está utilizando para verificar NULL en la cláusula where. Si tiene alguna declaración como SELECT * FROM tbl_name WHERE key_col IS NULL; luego, si key_col está indexado, la consulta se evaluará más rápido.

Optimización del diseño de almacenamiento para tablas InnoDB

1. En InnoDB, tener una LLAVE PRINCIPAL larga (ya sea una sola columna con un valor largo o varias columnas que forman un valor compuesto largo) desperdicia una gran cantidad de espacio en el disco. El valor de clave principal para una fila se duplica en todos los registros de índice secundarios que apuntan a la misma fila. Cree una columna AUTO_INCREMENT como clave principal si su clave principal es larga.
2. Utilice el tipo de datos VARCHAR en lugar de CHAR para almacenar cadenas de longitud variable o para columnas con muchos valores NULL. Una columna CHAR (N) siempre toma N caracteres para almacenar datos, incluso si la cadena es más corta o su valor es NULL. Las tablas más pequeñas encajan mejor en el grupo de búferes y reducen la E / S del disco.

Cuando se utiliza el formato de fila COMPACT (el formato InnoDB predeterminado) y los juegos de caracteres de longitud variable, como utf8 o sjis, las columnas CHAR (N) ocupan una cantidad variable de espacio, pero aún así tienen al menos N bytes.

3. Para las tablas que son grandes, o que contienen gran cantidad de texto repetitivo o datos numéricos, considere usar el formato de fila COMPRIMIDO. Se requiere menos E / S de disco para traer datos al grupo de búferes o para realizar exploraciones de tabla completas. Antes de tomar una decisión permanente, mida la cantidad de compresión que puede lograr utilizando el formato de fila COMPRIMIDO versus COMPACTO. Advertencia: los puntos de referencia rara vez se muestran mejor que la compresión 2: 1 y hay una gran cantidad de sobrecarga en el buffer_pool para COMPRESSED.
4. Una vez que sus datos alcancen un tamaño estable, o una tabla de crecimiento haya aumentado en decenas o en algunos cientos de megabytes, considere usar la instrucción OPTIMIZAR TABLA para reorganizar la tabla y compactar el espacio desperdiciado. Las tablas reorganizadas requieren menos E / S de disco para realizar exploraciones de tabla completas. Esta es una técnica sencilla que puede mejorar el rendimiento cuando otras técnicas, como mejorar el uso del índice o ajustar el código de la aplicación, no son prácticas. Advertencia : independientemente del tamaño de la mesa, OPTIMIZAR TABLA solo se debe realizar raramente. Esto se debe a que es costoso y rara vez mejora la tabla lo suficiente como para que valga la pena. InnoDB es razonablemente bueno para mantener sus árboles B + libres de una gran cantidad de espacio desperdiciado.

OPTIMIZE TABLE copia la parte de datos de la tabla y reconstruye los índices. Los beneficios provienen de un mejor empaquetamiento de los datos dentro de los índices y una fragmentación reducida dentro de los espacios de tablas y en el disco. Los beneficios varían dependiendo de los datos en cada tabla. Puede encontrar que hay ganancias significativas para algunos y no para otros, o que las ganancias disminuyen con el tiempo hasta que luego optimice la tabla. Esta operación puede ser lenta si la tabla es grande o si los índices que se están reconstruyendo no encajan en el grupo de búferes. La primera ejecución después de agregar una gran cantidad de datos a una tabla suele ser mucho más lenta que las posteriores.

Construyendo un índice compuesto

En muchas situaciones, un índice compuesto funciona mejor que un índice con una sola columna. Para crear un índice compuesto óptimo, rellénelo con columnas en este orden.

• = columna (s) de la cláusula WHERE primero. (por ejemplo, INDEX(a,b,...) para WHERE a=12 AND b='xyz' ... )
• IN columna (s); El optimizador puede ser capaz de saltar a través del índice.
• Un "rango" (por ejemplo, x BETWEEN 3 AND 9 , name LIKE 'J%' ) No usará nada más allá de la primera columna de rango.
• Todas las columnas en GROUP BY , en orden.
• Todas las columnas en ORDER BY , en orden. Funciona solo si todos son ASC o todos son DESC o si está usando 8.0.

Notas y excepciones:

• No duplique ninguna columna.
• Omita cualquier caso que no aplique.
• Si no usa todas las columnas de WHERE , no es necesario pasar a GROUP BY , etc.
• Hay casos en los que es útil indexar solo las columnas ORDER BY , ignorando WHERE .
• No "esconda" una columna en una función (por ejemplo, DATE(x) = ... no se puede usar x en el índice).
• Es poco probable que la indexación de 'Prefijo' (por ejemplo, text_col(99) ) sea útil; puede doler

Más detalles y consejos .