Optimizar la estructura de la base de datos.

Optimizar el tamaño de los datos

→ Reducir la cantidad de datos escritos y leídos desde el disco

→ Menos memoria principal mientras sus contenidos se procesan activamente durante la ejecución de la consulta

→ Da como resultado índices más pequeños que se pueden procesar más rápido

Columnas de tabla

• Utilice los tipos de datos más eficientes (más pequeños) posibles
• Declare las columnas como NO NULL si es posible → mejor uso de los índices y eliminando la sobrecarga para probar si cada valor es NULL.

Índices

• El índice principal de una tabla debe ser lo más corto posible
• Cree solo los índices que necesita para mejorar el rendimiento de las consultas. Los índices son buenos para la recuperación, pero ralentizan las operaciones de inserción y actualización.
• buscando en una combinación de columnas → crear un índice compuesto
• la primera columna del índice debe ser la que tenga más duplicados → para obtener una mejor compresión del índice.

Se une

• Declarar columnas con información idéntica en diferentes tablas con tipos de datos idénticos → mismo tipo de datos
• Mantenga los nombres de las columnas simples,

Normalización

• Normalmente, intenta que todos los datos no sean redundantes
• Si la velocidad es más importante que el espacio en disco y los costos de mantenimiento de mantener múltiples copias de datos

Optimizar el tipo de datos

• Para ID únicos u otros valores que se pueden representar como cadenas o números, → los valores numéricos se pueden almacenar en menos bytes que las cadenas correspondientes, más rápido y requiere menos memoria para transferirlos y compararlos.
• Al comparar valores de diferentes columnas, declare esas columnas con el mismo juego de caracteres y clasificación siempre que sea posible → evite conversiones de cadenas
• Para valores de columna de menos de 8 KB de tamaño, utilice VARCHAR binario en lugar de BLOB. Las cláusulas GROUP BY y ORDER BY pueden generar tablas temporales, y estas tablas temporales pueden usar el motor de almacenamiento MEMORY si la tabla original no contiene ninguna columna BLOB.
• Si una tabla contiene columnas de cadena y no se accede con frecuencia → se divide en otra tabla y se une → Cuando MySQL recupera cualquier valor de una fila, lee un bloque de datos que contiene todas las columnas de esa fila (y posiblemente otras filas adyacentes). Mantener cada fila pequeña, con solo las columnas utilizadas con más frecuencia, permite que quepan más filas en cada bloque de datos.
• Cuando utilices un valor generado aleatoriamente como clave principal en una tabla InnoDB, antepóngale un valor ascendente, como la fecha y hora actuales, si es posible.
• Para una tabla con varias columnas, para reducir los requisitos de memoria para consultas que no usan la columna BLOB, considere dividir la columna BLOB en una tabla separada y hacer referencia a ella con una consulta de unión cuando sea necesario
• • Dado que los requisitos de rendimiento para recuperar y mostrar un valor BLOB pueden ser muy diferentes de otros tipos de datos, puede colocar la tabla específica de BLOB en un dispositivo de almacenamiento diferente o incluso en un separado. instancia de base de datos. Por ejemplo, para recuperar un BLOB puede ser necesario realizar una lectura de disco secuencial de gran tamaño que se adapta mejor a un disco duro tradicional que a un dispositivo SSD.
• En lugar de probar la igualdad con una cadena de texto muy larga, puede almacenar un hash del valor de la columna en una columna separada, indexar esa columna y probar el valor hash en las consultas. (Utilice la función MD5() o CRC32() para generar el valor hash).

Optimización de sentencias SQL

Hemos encontrado útil analizar una consulta con bajo rendimiento en dos pasos:

• Descubre si tu aplicación está recuperando más datos de los que necesitas. Por lo general, eso significa que está accediendo a demasiadas filas, pero también puede que esté accediendo a demasiadas columnas.
• Descubre si el servidor MySQL está analizando más filas de las que necesita.

Optimización de declaraciones SELECT

• Evite el uso de funciones en predicados
• Evite el uso de un comodín (%) al comienzo de un predicado
• Utilice DISTINCT y UNION solo si es necesario