sql >> Base de Datos >  >> RDS >> MariaDB

Comprender los índices en MySQL:segunda parte

Esta publicación de blog es la segunda parte de una serie de blogs sobre índices en MySQL. En la primera parte de la serie de publicaciones de blog sobre los índices de MySQL, hemos cubierto muchas cosas, incluidos qué son, qué hacen, cuáles son sus tipos, cómo elegir los tipos de datos óptimos y los conjuntos de caracteres de MySQL para los índices que utiliza. . Repasamos los beneficios y los inconvenientes de usar índices en MySQL; le dijimos cómo elegir el mejor índice para usar, cómo mejorar el rendimiento de las consultas y asegurarse de que MySQL use sus índices, cuántos índices debe tener. También analizamos algunas consideraciones relacionadas con los motores de almacenamiento. Esta publicación de blog entrará en más detalles sobre algunos de los contenidos que hemos discutido en la primera parte de la serie. Comenzaremos con la correlación entre índices y motores de almacenamiento en MySQL.

Índices y motores de almacenamiento en MySQL

Como ya mencionamos en una publicación de blog anterior, puede haber algunos tipos de limitaciones para los índices y otras cosas si usa ciertos motores de almacenamiento en MySQL. Estos son algunos de ellos:ahora definiremos cuáles son (algunos de ellos se cubrieron en la primera parte de la serie de blogs, por lo que si nos falta algo, probablemente esté allí), luego cúbralos con más profundidad. análisis:

  • Según la documentación de MySQL, el número máximo de índices, la longitud máxima de la clave y la longitud máxima del índice es definido por motor de almacenamiento. Como ya mencionamos en una publicación anterior del blog, la cantidad máxima de índices por tablas MyISAM e InnoDB es 64, la cantidad máxima de columnas por índice en ambos motores de almacenamiento es 16, la longitud máxima de clave para InnoDB es 3500 bytes y la longitud máxima la longitud de la clave para MyISAM es de 1000 bytes.

  • No puede usar CREAR ÍNDICE para crear una CLAVE PRINCIPAL; use ALTERAR TABLA en su lugar.

  • Las columnas BLOB y TEXT se pueden indexar solo para tablas que ejecutan los motores de almacenamiento InnoDB, MyISAM y BLACKHOLE.

  • Si solo indexa un prefijo de la columna, tenga en cuenta que el soporte del prefijo y su longitud también son dependiente de los motores de almacenamiento. Un prefijo puede tener hasta 767 bytes de longitud para las tablas InnoDB que usan el formato de fila REDUNDANTE o COMPACTO, pero para los formatos de fila DINÁMICO o COMPRIMIDO, el límite de longitud del prefijo aumenta a 3072 bytes. Para las tablas MyISAM, el límite de longitud del prefijo es de 1000 bytes. El motor de almacenamiento NDB no admite prefijos en absoluto.

  • Si se habilita un modo SQL estricto y el prefijo del índice excede el tamaño máximo del tipo de datos de la columna, CREATE INDEX lanza un error. Si no se habilita un modo SQL estricto, CREATE INDEX genera una advertencia. Si se crea un ÍNDICE ÚNICO, se produce un error.

  • En general, MySQL solo le permite crear hasta 16 índices en una tabla dada.

  • Si está utilizando un índice PRIMARY KEY, solo puede tener una clave principal por tabla. TEXTO COMPLETO, ÍNDICES ÚNICOS e ÍNDICES no tienen esta limitación.

  •  Si está utilizando índices FULLTEXT, tenga en cuenta que solo se pueden utilizar para motores de almacenamiento InnoDB o MyISAM y para las columnas CHAR, VARCHAR o TEXT. También tenga en cuenta que MySQL solo usa índices FULLTEXT cuando se usan las cláusulas MATCH() AGAINST() y que puede tener un índice y un índice de texto completo en la misma columna al mismo tiempo si así lo desea y que los índices FULLTEXT tienen su propio conjunto de palabras vacías, cada una específica para los motores de almacenamiento en uso.

  • Los índices B-Tree pueden ser útiles si usa consultas LIKE que comienzan con un comodín, pero solo en ciertas escenarios.

Conocer estas limitaciones de índice debería ser útil si está tratando de entender cómo funcionan los índices en MySQL. Sin embargo, lo que es aún más importante de entender es el hecho de que debe verificar que MySQL realmente use sus índices. Hemos abordado esto brevemente en la primera parte de esta serie ("¿Cómo elegir el mejor índice para usar?"), pero no le hemos dicho cómo verificar que MySQL realmente use sus índices. Para hacer eso, verifique su uso usando EXPLAIN:cuando EXPLAIN se usa junto con una declaración explicable, MySQL muestra información del optimizador sobre el plan de ejecución de la declaración.

Consideraciones de la CLAVE PRINCIPAL

Algunas de las consideraciones básicas relacionadas con los índices PRIMARY KEY en MySQL incluyen el hecho de que se usan principalmente para identificar registros de forma única en una tabla y se usan con frecuencia con valores AUTO_INCREMENTing, lo que significa que pueden ser muy útiles si está creando, por ejemplo, campos de identificación. Los campos PRIMARY KEY deben contener valores únicos y no pueden contener valores NULL.

Coincidencia de un prefijo de columna

Los índices también pueden coincidir con un prefijo de columna. Este enfoque de los índices puede ser útil si sus columnas son columnas de cadena y cree que agregar un índice en toda la columna podría consumir una gran cantidad de espacio en disco. Sus índices pueden coincidir con un prefijo de columna así:

ALTER TABLE demo_table ADD INDEX index_name(column_name(length));

La consulta anterior agregaría un índice index_name en una columna denominada column_name solo para un prefijo de columna definido. Para elegir una buena cantidad de longitud para indexar, asegúrese de que su uso del prefijo maximice la exclusividad de los valores en la columna:encuentre el número de filas en la tabla y evalúe diferentes longitudes de prefijo hasta que logre la exclusividad de filas deseada.

Índices de TEXTO COMPLETO en MySQL

Los índices FULLTEXT en MySQL son una bestia completamente diferente. Tienen muchas limitaciones únicas (por ejemplo, InnoDB tiene una lista de palabras vacías compuesta por 36 palabras, mientras que la lista de palabras vacías de MyISAM está compuesta por 143 palabras), también tienen modos de búsqueda únicos. Algunos de ellos incluyen un modo de lenguaje natural (para activar dicho modo de búsqueda, ejecute una consulta de búsqueda de TEXTO COMPLETO sin modificadores), también puede expandir su búsqueda (para hacer eso, use el modificador CON EXPANSIÓN DE LA CONSULTA; dicho modo de búsqueda realiza el buscar dos veces, pero cuando la búsqueda se ejecuta por segunda vez, incluye algunos de los registros más relevantes de la primera búsqueda (se usa con frecuencia cuando un usuario tiene conocimiento implícito de algo), para buscar con operadores booleanos, use el modificador IN BOOLEAN MODE. Los índices FULLTEXT solo se utilizarán si la consulta de búsqueda consta de un mínimo de tres caracteres para InnoDB y un mínimo de cuatro caracteres para MyISAM.

Uso de índices B-Tree con comodines

Los índices también se usan con frecuencia si está creando algo similar a los motores de búsqueda. Para eso, con frecuencia desea buscar solo una parte de un valor y devolver los resultados:aquí es donde intervienen los comodines. Una consulta simple que usa un comodín usa una consulta LIKE y el signo % para significar "cualquier cosa" después del texto. Por ejemplo, una consulta como esta buscaría resultados que comenzaran con la palabra "buscar" y que tuviera algo después:

SELECT * FROM … WHERE demo_column LIKE ‘search%’;

Una consulta como esta buscaría resultados que comenzaran con cualquier cosa, con la palabra "buscar" y cualquier cosa después:

SELECT * FROM … WHERE demo_column LIKE ‘%search%’;

Pero aquí hay un problema:la consulta anterior no usará un índice. ¿Por qué? Porque tiene un comodín al comienzo de sí mismo y MySQL no puede averiguar con qué necesita comenzar la columna. Es por eso que dijimos que los índices comodín tienen su lugar, pero solo en escenarios específicos, es decir, escenarios en los que no tiene un comodín al comienzo de su consulta de búsqueda.

Uso de ClusterControl para monitorear el rendimiento de las consultas

Además de usar EXPLAIN, también puede usar ClusterControl para monitorear el rendimiento de sus consultas:ClusterControl proporciona un conjunto de funciones avanzadas de monitoreo e informes que le permiten realizar un seguimiento del rendimiento de las instancias y consultas de su base de datos. . Por ejemplo, haga clic en un clúster y verá la pestaña "Consultar monitor". Haga clic en él y ClusterControl le permitirá observar el estado de sus consultas en las instancias de su base de datos:

Esta parte de ClusterControl le permite ver una lista de los principales archivos lentos y largos. ejecutar consultas y al mismo tiempo permitirle filtrarlas. Por ejemplo, si sabe que no hace mucho ejecutó una consulta que consistía en @@log_bin, simplemente puede buscar el término y ClusterControl le devolverá una lista de resultados:

Como probablemente notó, también puede filtrar consultas por hosts que utiliza o por ocurrencias, también puede optar por ver un conjunto de filas, por ejemplo, 20, 100 o 200. ClusterControl también le dirá cuándo se vio por última vez la consulta, cuál fue su tiempo total de ejecución, cuántas filas había devuelto, cuántas filas examinó y así sucesivamente. ClusterControl puede resultar fundamental si desea observar cómo las instancias de MySQL, MariaDB, MongoDB, PostgreSQL o TimescaleDB utilizan realmente sus índices.

Resumen

En esta publicación de blog, analizamos algunas limitaciones y beneficios relacionados con los índices en MySQL y también cubrimos cómo ClusterControl puede ayudarlo a lograr sus objetivos de rendimiento de la base de datos. También tendremos una tercera parte sobre los índices en MySQL profundizando aún más en ellos, pero para concluir lo que hemos cubierto hasta ahora, tenga en cuenta que los índices en MySQL ciertamente tienen su propio lugar:para aprovecharlos al máximo, sepa cómo interactúan con los motores de almacenamiento, sus beneficios y limitaciones, cómo y cuándo usar ciertos tipos de índices y elegir sabiamente.