¡Obtenga información técnica sobre productos secos e información de la industria por primera vez!
De hecho, todos los amigos que me siguieron en los primeros días saben que escribí un MySQL en la consulta de si puede ir al índice o no. Hoy, echemos un vistazo a si la consulta Me gusta de MySQL se indexará si el signo de porcentaje está al frente.
En el proceso de entrevista, generalmente decimos que existe un principio de indexación similar, es decir, el principio de coincidencia del extremo izquierdo. Entonces, cuando el signo de% se coloca al frente, ¿el índice definitivamente no tiene lugar?
Usemos un ejemplo para ver si este es el caso. Publiqué el SQL de muestra de una vez, como se muestra a continuación:
Tenga en cuenta que mi versión es MySQL 5.6. El plan de ejecución de las consultas anteriores de 1 a 5 es básicamente el siguiente:
Según mi artículo anterior, "¡Por favor, no me pregunte acerca de la optimización del rendimiento de MySQL!" 》 Sabemos que todas las consultas anteriores utilizan índices. Pero tenga en cuenta que en la tercera consulta, possible_keys es nulo. Possible_keys representa el índice que se puede usar en esta consulta, lo que significa que la consulta like que pone% al principio parece usar un índice, pero el resultado mostrado por possible_keys nos dice que el índice no se usa. ¿Cuál es la situación actual?
Ahora podemos llegar a una conclusión: en MySQL 5.6, la consulta Like usará el índice, pero siempre que el% sea el primero, el índice se escaneará secuencialmente, lo que no se puede ubicar rápidamente y requiere un recorrido secuencial. En cuanto a la ausencia de%, también se utilizará un índice. no como lo mismo.
Pero no seas feliz demasiado pronto. Existe una diferencia entre "usar índice" y "usar índice para localizar rápidamente registros". Un uso de "índice de uso" es "índice de exploración secuencial".
Like'y 'o'y%' puede utilizar el índice y localizar rápidamente el registro. Como '% y' o '% y%', simplemente atraviesa el árbol de índice secundario para encontrar registros y no puede ubicarlos rápidamente (escanear todo el árbol de índice). Cuando solo hay campos id y test_like, las 5 consultas similares anteriores, el índice test_like puede cumplir las condiciones de consulta de id y test_like, y no hay necesidad de volver a la tabla, así que elegí usar el árbol de índices de test_like para resolver el problema. Si el campo xtt se agregó recientemente, pero no hay un índice conjunto (test_like, xtt), si usa el árbol de índice test_like, debe volver a la tabla. Escanee el árbol de índice de clave primaria directamente en el tipo '% y' o '% y%', el fenómeno es que no se usa el índice test_like. Se agrega el campo xtt y también se agrega el índice (test_like, xtt). El uso del índice de cobertura puede satisfacer la consulta select * field sin volver a la tabla, por lo que se usa el árbol de índice (test_like, xtt). Pero solo como 'y' y 'y%' pueden localizar rápidamente registros, y como '% y' y '% y%' también pueden usar el árbol de índice, pero no se pueden ubicar rápidamente y deben recorrerse en orden.
En segundo lugar, el tipo de índice significa "lo mismo que un escaneo de tabla completo. Es solo que al escanear la tabla, se hace en orden de índice en lugar de filas. La principal ventaja es que se evita la clasificación, pero la sobrecarga sigue siendo muy grande. El índice indica que el rendimiento no es particularmente superior, system> const> eq_ref> ref> fulltext> ref_or_null> index_merge> unique_subquery> index_subquery> range> index> ALL. En general, es necesario asegurarse de que la consulta alcance al menos el rango nivel, preferiblemente el nivel de rango.