¡Obtenga información técnica sobre productos secos e información de la industria por primera vez!
No saludes, miserable desarrollo. Se acerca una gran ola de preguntas de la entrevista de Redis
¿Conoce todas las preguntas de la entrevista de MySQL que debe hacer BAT?
¿Cómo aprender el protocolo web capturando el paquete real?
MVCC de la tecnología de procesamiento de alta concurrencia de MySQL
Enseñarle a construir una arquitectura clásica de replicación maestro-esclavo de MySQL
Es posible que nunca haya oído hablar del término formulario de devolución, pero debe haberlo utilizado en su trabajo real. Si no ha oído hablar de volver a la mesa, entonces creo que no importa cuánto conocimiento de la optimización de SQL mire, todavía está en la superficie. Incluso si ha leído mi artículo anterior "¡No me pregunte acerca de la optimización del rendimiento de MySQL!" ".
Echemos un vistazo a lo que está de vuelta a la mesa.
En términos simples, si la columna del índice está en la columna que la selección necesita obtener (porque el índice en mysql está ordenado de acuerdo con el valor de la columna del índice, por lo que hay valores parciales en la columna del índice nodo) o de acuerdo con una consulta de índice Puede obtener registros sin volver a la tabla. Si hay una gran cantidad de columnas no indexadas en las columnas que seleccione necesita obtener, el índice debe encontrar la información de la columna correspondiente en la tabla. , que se llama volver a la mesa.
De acuerdo con este concepto, cuando usa Explain para ejecutar un plan de consulta, cuando usa index, using where, using index condition, etc., aparece en el resultado, cree que se usa la condición de filtro, se usa el índice y el SQL la optimización no está mal. En realidad, este es un entendimiento incorrecto.
Porque usar el índice no significa que la consulta sea óptima. Como se puede ver al usar la condición de índice, usar índice y usar dónde, etc., esta declaración SQL se devuelve realmente a la tabla.
A veces, después de comprobar el plan de ejecución de Explain, se da cuenta de que el índice obviamente se ha ido. ¿Por qué sigue siendo lento? Puede que vuelva a la mesa. A continuación usamos un ejemplo para ilustrar lo que está de vuelta a la mesa. Primero cree una tabla, la declaración sql es la siguiente:
create table xttblog (
id int primary key,
k int not null,
name varchar (16),
index (k)
) engine = InnoDB;
Luego, ejecutamos la siguiente declaración SQL e insertamos algunos datos de prueba.
Supongamos que ahora queremos consultar los datos con id 2. Luego ejecute select * from xttblog donde ID = 2; Esta declaración SQL no necesita regresar a la tabla. La razón es que de acuerdo con el modo de consulta de la clave primaria, solo es necesario buscar en el árbol B + de ID. La clave principal es única y, basándose en este índice único, MySQL puede determinar el registro que se buscará.
Pero cuando usamos el índice k para consultar k = 2 registros, necesitamos usar la tabla posterior. seleccione * de xttblog donde k = 2; La razón es que a través del método de consulta de índice normal de k, primero debe buscar en el árbol de índice k, y luego obtener el valor de la ID de la clave principal en 1, y luego buscar la ID árbol de índice de nuevo. Aunque el índice se usa en este proceso, la capa inferior en realidad realiza dos consultas de índice, este proceso se llama regresar a la tabla.
En otras palabras, las consultas basadas en índices de claves no primarias deben escanear un árbol de índices más. Por lo tanto, deberíamos intentar utilizar consultas de clave primaria en nuestras aplicaciones.
La cantidad de datos en la tabla aquí es relativamente pequeña. Si la cantidad de datos es grande, puede ver claramente el tiempo que tardan las dos consultas. Obviamente, usar la consulta de clave primaria es más eficiente.
¡Rara vez veo lo mencionado anteriormente en las reglas de optimización de SQL! ¡Espero ayudar a todos!