¿Ha practicado la optimización del rendimiento de MySQL?

Prefacio

La dificultad de la entrevista de BATJTMD y otras grandes fábricas es cada vez mayor, pero no importa de la gran fábrica a la pequeña empresa, un punto clave que no ha cambiado es la inspección de la experiencia de optimización de SQL. Cuando se trata de bases de datos, primero "cuéntenos su opinión sobre la optimización de SQL".

La optimización SQL se ha convertido en un indicador rígido para medir la excelencia de los programadores, e incluso las funciones de los puestos de contratación en las principales fábricas están claramente marcadas. Si es usted, ¿se le puede dar una palmada al entrevistador en este tema o se le va a dar una palmada?

Nota: si se ve borroso, es posible que esté demasiado

Tabla de contenido

Prefacio

SELECCIONE el orden gramatical de la declaración:

SELECCIONAR orden de ejecución de instrucciones:

Estrategia de optimización de SQL

1. Evite escenas que no se indexen

2. Otras optimizaciones de la instrucción SELECT

Tres, agregar, eliminar y modificar la optimización de la declaración DML

Cuarto, optimización de las condiciones de consulta

Cinco, optimización de la construcción de mesas


Un amigo preguntó: ¿es realmente tan importante la optimización de SQL? Como se muestra en la figura siguiente, la optimización de SQL es la forma de mejorar el rendimiento del sistema (el costo más bajo y el efecto de optimización más obvio). Si su equipo es muy bueno en optimización de SQL, sin duda será un salto cualitativo en la disponibilidad de todo su sistema a gran escala, y realmente le ahorrará a su jefe más que unos pocos dólares.

  • Optimice el costo: hardware> configuración del sistema> estructura de la tabla de la base de datos> SQL e índice.

  • Efecto de optimización: hardware <configuración del sistema <estructura de la tabla de la base de datos <SQL e índice.

String result = "嗯,不错,";
 
if ("SQL优化经验足") {
    if ("熟悉事务锁") {
        if ("并发场景处理666") {
            if ("会打王者荣耀") {
                result += "明天入职" 
            }
        }
    }
} else {
    result += "先回去等消息吧";
} 
 
Logger.info("面试官:" + result );

No lo lea, lo anterior es una propuesta.

Bueno, volvamos al negocio. En primer lugar, generalmente sigo cinco principios para la optimización de la capa de MySQL:

  1. Reduzca el acceso a los datos: establezca tipos de campo razonables, habilite la compresión, reduzca la E / S del disco a través del acceso al índice, etc.

  2. Devuelve menos datos: solo devuelve los campos y datos obligatorios. El procesamiento de paginación reduce la io del disco y la io de la red

  3. Reducir el número de interacciones: operaciones DML por lotes, almacenamiento de funciones, etc. para reducir el número de conexiones de datos

  4. Reduzca la sobrecarga de la CPU del servidor: minimice las operaciones de clasificación de la base de datos y las consultas de tablas completas, y reduzca el uso de la memoria de la CPU

  5. Utilizar más recursos: el uso de particiones de tabla puede aumentar las operaciones paralelas y maximizar el uso de los recursos de la CPU

Resumiendo la optimización de SQL, hay tres puntos:

  • Maximizar el uso de índices;

  • Evite los escaneos de tablas completas tanto como sea posible;

  • Reducir las consultas de datos no válidos;

Para comprender el principio de optimización de SQL, primero debemos averiguar el orden de ejecución de SQL:

SELECCIONE el orden gramatical de la declaración:

1. SELECT 
2. DISTINCT <select_list>
3. FROM <left_table>
4. <join_type> JOIN <right_table>
5. ON <join_condition>
6. WHERE <where_condition>
7. GROUP BY <group_by_list>
8. HAVING <having_condition>
9. ORDER BY <order_by_condition>
10.LIMIT <limit_number>

SELECCIONAR orden de ejecución de instrucciones:

FROM
<nombre de la tabla> # Seleccione una tabla y convierta los datos de varias tablas en una tabla mediante el producto cartesiano.
ON
<condiciones de filtro> # Filtrar la tabla virtual del producto cartesiano
JOIN  <unión, unión izquierda, unión derecha ...> 
<tabla de unión> # Especificar unión, que se utiliza para agregar datos a la tabla virtual después de, como left Join agregará los datos restantes de la tabla de la izquierda a la tabla virtual
DONDE
<condición de donde> # filtrar la tabla virtual anterior
GROUP BY
<condición de agrupación> # agrupación
<SUM () y otras funciones agregadas> # utilizado para el juicio del Tener cláusula, Por escrito, este tipo de función agregada está escrito en
HAVING
<agrupamiento y filtrado> en el juicio de tener # Realizar agregación y filtrado en los resultados agrupados
SELECCIONAR
<Lista de datos de retorno> # La única columna devuelta debe estar en el grupo por cláusula, excepto para la función agregada
DISTINCT
# Eliminación de peso de datos
ORDER BY
<condición de clasificación> # sort
LIMIT
<límite de número de fila>

Estrategia de optimización de SQL

Aviso legal: La siguiente estrategia de optimización SQL es adecuada para escenarios con gran cantidad de datos, si la cantidad de datos es pequeña, no es necesario tomar esto como criterio para evitar superfluos.

1. Evite escenas que no se indexen

1. Intente evitar consultas difusas al principio del campo, lo que provocará que el motor de la base de datos abandone el índice y realice una exploración completa de la tabla. como sigue:

SELECT * FROM t WHERE username LIKE '%陈%'

Método de optimización: intente utilizar una consulta difusa detrás del campo. como sigue:

SELECT * FROM t WHERE username LIKE '陈%'

Si el requisito es utilizar una consulta difusa al frente,

  • Use la función incorporada de MySQL INSTR (str, substr) para hacer coincidir, similar a indexOf () en java, consulte la posición del subíndice donde aparece la cadena

  • Utilice el índice de texto completo de texto completo, busque con coincidencia

  • En el caso de una gran cantidad de datos, se recomienda utilizar ElasticSearch, solr, y la velocidad de recuperación de cientos de millones de datos es en segundos.

  • Cuando la cantidad de datos en la tabla es pequeña (miles de elementos), no sea demasiado sofisticado, simplemente use como '% xx%'.

2. Trate de evitar usar in y no in, lo que hará que el motor realice un escaneo completo de la tabla. como sigue:

SELECT * FROM t WHERE id IN (2,3)

Método de optimización: si es un valor continuo, puede utilizar entre en su lugar. como sigue:

SELECT * FROM t WHERE id BETWEEN 2 AND 3

Si es una subconsulta, puede usar existe en su lugar. como sigue:

-- 不走索引
select * from A where A.id in (select id from B);
-- 走索引
select * from A where exists (select * from B where B.id = A.id);

3. Intente evitar el uso de o, lo que provocará que el motor de la base de datos abandone el índice para escaneos completos de tablas. como sigue:

SELECT * FROM t WHERE id = 1 OR id = 3

Método de optimización: Union se puede utilizar en lugar de o. como sigue:

SELECT * FROM t WHERE id = 1
   UNION
SELECT * FROM t WHERE id = 3

4. Intente evitar juzgar el valor nulo, lo que hará que el motor de la base de datos abandone el índice y realice una exploración completa de la tabla. como sigue:

SELECT * FROM t WHERE score IS NULL

Método de optimización: puede agregar un valor predeterminado de 0 al campo y juzgar el valor de 0. como sigue:

SELECT * FROM t WHERE score = 0

5. Trate de evitar realizar expresiones y operaciones de funciones en el lado izquierdo del signo igual en la condición where, lo que hará que el motor de la base de datos abandone el índice para escaneos completos de tablas.

Puede mover expresiones y operaciones de funciones a la derecha del signo igual. como sigue:

-- 全表扫描
SELECT * FROM T WHERE score/10 = 9
-- 走索引
SELECT * FROM T WHERE score = 10*9

6. Cuando la cantidad de datos sea grande, evite usar la condición donde 1 = 1. Por lo general, para facilitar el ensamblaje de las condiciones de consulta, usaremos esta condición por defecto, y el motor de la base de datos abandonará el índice y realizará un escaneo completo de la tabla. como sigue:

SELECT username, age, sex FROM T WHERE 1=1

Método de optimización: juzgue al ensamblar sql con código, elimine where si no hay una condición where, y agregue y si hay una condición where.

7. Las condiciones de consulta no pueden utilizar <> o! =

Cuando realice consultas utilizando columnas de índice como condiciones, evite utilizar condiciones de juicio como <> o! =. Si realmente necesita usar el símbolo desigual, debe volver a evaluar el índice para evitar crear un índice en este campo y reemplazarlo con otros campos de índice en la condición de consulta.

8. La condición where contiene solo la columna no inicial del índice compuesto.

De la siguiente manera: el índice compuesto (conjunto) contiene tres columnas de key_part1, key_part2 y key_part3, pero la declaración SQL no incluye la precolumna de índice "key_part1". De acuerdo con el principio de coincidencia más a la izquierda del índice conjunto MySQL, el no se utilizará el índice.

select col1 from table where key_part2=1 and key_part3=2

9. La conversión de tipo implícita no genera índice

En la siguiente instrucción SQL, dado que el índice es varchar para el tipo de columna, pero el valor dado es un valor numérico, implica una conversión de tipo implícita, lo que hace que el índice sea incorrecto.

select col1 from table where col_varchar=123;

10. El orden por condiciones debe ser consistente con las condiciones en donde, de lo contrario, el orden por no usará el índice para ordenar.

-- 不走age索引
SELECT * FROM t order by age;
 
-- 走age索引
SELECT * FROM t where age > 0 order by age;

Para la declaración anterior, la secuencia de procesamiento de la base de datos es:

  • El primer paso: generar un plan de ejecución basado en las condiciones del lugar y la información estadística, y obtener los datos.

  • Paso 2: Ordena los datos obtenidos. Cuando se ejecutan los datos de procesamiento (orden por), la base de datos primero verificará el plan de ejecución del primer paso para ver si el orden por campo utiliza un índice en el plan de ejecución. Si es así, puede utilizar el orden de índice para obtener directamente los datos ordenados. Si no es así, se vuelve a realizar la operación de clasificación.

  • Paso 3: Devuelve los datos ordenados.

Cuando el campo ordenado por aparece en la condición where, se utilizará el índice en lugar de la ordenación secundaria. Más precisamente, cuando el campo ordenado por usa el índice en el plan de ejecución, la operación de ordenación no es necesaria.

Esta conclusión no solo es válida para ordenar por, sino también para otras operaciones que requieren clasificación. Como grupo por, unión, distinto, etc.

11. Utilice correctamente las declaraciones de optimización de sugerencias

En MySQL, puede usar sugerencias para especificar que el optimizador selecciona o ignora índices específicos durante la ejecución. En términos generales, en los cambios de índice de estructura de la tabla provocados por cambios de versión, es más recomendable evitar el uso de sugerencias, pero recopilar más información estadística a través de Analizar tabla. Sin embargo, en determinadas situaciones, especificar sugerencias puede eliminar la interferencia de otros índices y especificar un mejor plan de ejecución.

  1. USE INDEX Después del nombre de la tabla en su declaración de consulta, agregue USE INDEX para proporcionar una lista de índices a los que desea que MySQL se refiera, de modo que MySQL ya no pueda considerar otros índices disponibles. Ejemplo: SELECT col1 FROM table USE INDEX (mod_time, name) ...

  2. IGNORE INDEX Si simplemente desea que MySQL ignore uno o más índices, puede usar IGNORE INDEX como sugerencia. Ejemplo: SELECT col1 FROM table IGNORE INDEX (prioridad) ...

  3. FORCE INDEX Para forzar a MySQL a usar un índice específico, puede usar FORCE INDEX como una pista en la consulta. Ejemplo: SELECT col1 FROM table FORCE INDEX (mod_time) ...

Al realizar una consulta, el sistema de base de datos analizará automáticamente la declaración de la consulta y seleccionará el índice más adecuado. Pero en muchos casos, es posible que el optimizador de consultas del sistema de base de datos no siempre utilice el índice óptimo. Si sabemos cómo elegir un índice, podemos usar FORCE INDEX para forzar que la consulta use el índice especificado.

P.ej:

SELECT * FROM students FORCE INDEX (idx_class_id) WHERE class_id = 1 ORDER BY id DESC;

2. Otras optimizaciones de la instrucción SELECT

1. Evite seleccionar *

En primer lugar, la operación select * no es un buen hábito de escritura SQL en ningún tipo de base de datos.

El uso de seleccionar * para eliminar todas las columnas hará que el optimizador no pueda completar optimizaciones tales como escaneos de cobertura de índice, afectará la elección del plan de ejecución del optimizador, también aumentará el consumo de ancho de banda de la red y traerá E / S, memoria y consumo de CPU adicionales.

Se recomienda indicar la cantidad de columnas que realmente requiere la empresa y especificar los nombres de las columnas para reemplazar select *.

2. Evite funciones con resultados inciertos

Específicamente para escenarios comerciales como la replicación maestro-esclavo. Dado que, en principio, las declaraciones ejecutadas por la biblioteca principal se copian de la biblioteca, el uso de funciones con resultados inciertos como now (), rand (), sysdate (), current_user (), etc.puede conducir fácilmente a datos inconsistentes entre la biblioteca principal biblioteca y la biblioteca esclava. Además, para funciones con valores inciertos, las sentencias SQL generadas no pueden utilizar la caché de consultas.

3. Cuando se trata de consultas relacionadas con varias tablas, la mesa pequeña está al frente y la mesa grande está al fondo.

En MySQL, la consulta de asociación de tablas después de ejecutar desde se ejecuta de izquierda a derecha (lo opuesto a Oracle), la primera tabla implicará un escaneo de tabla completo, así que coloque la tabla pequeña al frente, escanee primero la tabla pequeña y el escaneo es rápido y eficiente. Más alto, después de escanear la tabla grande, quizás solo escanear las primeras 100 filas de la tabla grande cumple la condición de devolución y devuelve.

Por ejemplo: la Tabla 1 tiene 50 datos y la Tabla 2 tiene 3000 millones de datos; si toda la tabla escanea la Tabla 2, tendrá una comida, ¿verdad?

4. Usa alias de tablas

Cuando conecte varias tablas en una declaración SQL, utilice el alias de la tabla y anteponga el alias a cada nombre de columna. Esto puede reducir el tiempo de análisis y reducir los errores gramaticales causados ​​por la ambigüedad de los nombres de las columnas de amigos.

5. Reemplaza la oración HAVING por la oración where.

Evite usar la oración HAVING, porque HAVING solo filtrará el conjunto de resultados después de que se recuperen todos los registros, mientras que where es limpiar los registros antes de la agregación. Si el número de registros se puede limitar por la oración where, esto se puede reducir. . Las condiciones en HAVING se usan generalmente para filtrar funciones agregadas, además, las condiciones deben escribirse en la cláusula where.

La diferencia entre where y have: las funciones de grupo no se pueden usar detrás de where

6. Ajuste el orden de conexión en la oración Where

MySQL utiliza un orden de arriba hacia abajo de izquierda a derecha para analizar la cláusula where. De acuerdo con este principio, las condiciones para filtrar más datos deben establecerse para reducir el conjunto de resultados lo más rápido posible.

Tres, agregar, eliminar y modificar la optimización de la declaración DML

1. Insertar datos de forma masiva

Si realiza una gran cantidad de inserciones al mismo tiempo, se recomienda utilizar varias instrucciones INSERT (método 2). Esto es más rápido que usar instrucciones INSERT por separado (método uno). Generalmente, la eficiencia de la inserción de lotes es varias veces diferente.

método uno:

insert into T values(1,2); 
 
insert into T values(1,3); 
 
insert into T values(1,4);

Método dos:

Insert into T values(1,2),(1,3),(1,4);

Hay tres razones para elegir este último método.

  • Reduzca la operación de análisis de sentencias SQL. MySQL no tiene un grupo de recursos compartidos similar a Oracle. Con el método dos, la inserción de datos se puede realizar sólo analizando una vez;

  • Puede reducir la cantidad de conexiones DB en ciertos escenarios.

  • La instrucción SQL es más corta, lo que puede reducir el IO de la transmisión de red.

2. Utilice la confirmación de forma adecuada

El uso apropiado del compromiso puede liberar los recursos ocupados por la transacción y reducir el consumo. Los recursos que se pueden liberar después del compromiso son los siguientes:

  • El bloque de datos de deshacer ocupado por la transacción;

  • El bloque de datos registrado por la transacción en el registro de rehacer;

  • Libere la transacción impuesta para reducir la contención de bloqueo y afectar el rendimiento. Especialmente cuando necesita usar delete para eliminar una gran cantidad de datos, debe desglosar la cantidad eliminada y confirmar regularmente.

3. Evite las consultas repetidas de datos actualizados

En respuesta a la necesidad de actualizar filas que aparecen a menudo en el negocio mientras se desea obtener información de cambio de fila, MySQL no admite la sintaxis UPDATE RETURNING como PostgreSQL, que se puede implementar mediante variables en MySQL.

Por ejemplo, para actualizar la marca de tiempo de una fila de registros, y al mismo tiempo querer consultar qué marca de tiempo está almacenada en el registro actual, se logra un método simple:

Update t1 set time=now() where col1=1; 
 
Select time from t1 where id =1; 

El uso de variables se puede reescribir de la siguiente manera:

Update t1 set time=now () where col1=1 and @now: = now (); 
 
Select @now; 

Tanto el anverso como el reverso requieren dos viajes de ida y vuelta de red, pero el uso de variables evita volver a acceder a la tabla de datos, especialmente cuando la tabla t1 tiene una gran cantidad de datos, esta última es mucho más rápida que la primera.

4. Prioridad de consulta o prioridad de actualización (insertar, actualizar, eliminar)

MySQL también permite cambiar la prioridad de la programación de sentencias Puede hacer que las consultas de varios clientes funcionen mejor juntas para que un solo cliente no espere mucho tiempo debido a bloqueos. Cambiar la prioridad también puede garantizar que ciertos tipos de consultas se procesen más rápido. Primero debemos determinar el tipo de aplicación, determinar si la aplicación está orientada a consultas u orientada a actualizaciones, ya sea para garantizar la eficiencia de las consultas o la eficiencia de las actualizaciones, y decidir si la prioridad de consulta o la prioridad de actualización.

El método para cambiar la estrategia de programación que se menciona a continuación es principalmente para motores de almacenamiento que solo tienen bloqueos de tabla, como MyISAM, MEMROY y MERGE. Para los motores de almacenamiento Innodb, la ejecución de las sentencias está determinada por el orden en que se encuentran los bloqueos de fila adquirido. La estrategia de programación predeterminada de MySQL se puede resumir de la siguiente manera:

1) La operación de escritura tiene prioridad sobre la operación de lectura.

2) La operación de escritura en una determinada tabla de datos solo puede ocurrir una vez en un momento determinado, y las solicitudes de escritura se procesan en el orden en que llegan.

3) Se pueden realizar simultáneamente varias operaciones de lectura de una determinada tabla de datos. MySQL proporciona varios modificadores de declaraciones que le permiten modificar su estrategia de programación:

  • La palabra clave LOW_PRIORITY se aplica a DELETE, INSERT, LOAD DATA, REPLACE y UPDATE;

  • La palabra clave HIGH_PRIORITY se utiliza en sentencias SELECT e INSERT;

  • La palabra clave DELAYED se aplica a las instrucciones INSERT y REPLACE.

Si la operación de escritura es una solicitud LOW_PRIORITY (prioridad baja), entonces el sistema no considerará su prioridad más alta que la operación de lectura. En este caso, si el segundo lector llega mientras el escritor está esperando, entonces el segundo lector puede insertar antes que el escritor. Los escritores pueden iniciar operaciones solo cuando no hay otros lectores. Esta modificación de programación puede hacer que la operación de escritura LOW_PRIORITY se bloquee para siempre.

La palabra clave HIGH_PRIORITY (prioridad alta) de la consulta SELECT es similar. Permite insertar SELECT antes de la operación de escritura en espera, incluso si la prioridad de la operación de escritura es mayor en circunstancias normales. Otro efecto es que los SELECT de alta prioridad se ejecutan antes que las instrucciones SELECT normales, porque estas instrucciones serán bloqueadas por operaciones de escritura. Si desea que todas las declaraciones que admiten la opción LOW_PRIORITY se procesen como de baja prioridad de forma predeterminada, use la opción --low-priority-updates para iniciar el servidor. Al usar INSERTHIGH_PRIORITY para aumentar la instrucción INSERT a la prioridad de escritura normal, se puede eliminar el efecto de esta opción en una sola instrucción INSERT.

Busque la cuenta pública de Java PhoenixMiles, responda a la "entrevista de back-end" y envíele una copia de Java Interview Questions.pdf

Cuarto, optimización de las condiciones de consulta

1. Para consultas complejas, puede utilizar tablas temporales intermedias para almacenar datos temporalmente.

2. Optimice el grupo por declaración

Por defecto, MySQL ordenará todos los valores del grupo GROUP BY, como "GROUP BY col1, col2, ...;" El método de consulta es como especificar "ORDER BY col1, col2, ...;" en la consulta Si incluye explícitamente una cláusula ORDER BY que contiene las mismas columnas, MySQL puede optimizarla sin ralentizarse, incluso si todavía se ordena.

Por lo tanto, si la consulta incluye GROUP BY pero no desea ordenar los valores agrupados, puede especificar ORDER BY NULL para prohibir la ordenación. P.ej:

SELECT col1, col2, COUNT(*) FROM table GROUP BY col1, col2 ORDER BY NULL ;

3. Optimice la declaración de unión

En MySQL, puede usar la instrucción SELECT para crear un resultado de consulta de una sola columna a través de una subconsulta y luego usar este resultado como una condición de filtro en otra consulta. El uso de subconsultas puede completar muchas operaciones SQL que lógicamente requieren varios pasos para completarse a la vez. Al mismo tiempo, también puede evitar bloqueos de transacciones o tablas y es fácil de escribir. Sin embargo, en algunos casos, las subconsultas se pueden reemplazar por combinaciones más eficientes (JOIN).

Ejemplo: suponga que desea eliminar a todos los usuarios que no tienen registros de pedidos, puede utilizar la siguiente consulta para completar:

SELECT col1 FROM customerinfo WHERE CustomerID NOT in (SELECT CustomerID FROM salesinfo )

Si usa JOIN .. para completar esta consulta, se mejorará la velocidad. Especialmente cuando hay un índice de CustomerID en la tabla salesinfo, el rendimiento será mejor. La consulta es la siguiente:

SELECT col1 FROM customerinfo 
   LEFT JOIN salesinfoON customerinfo.CustomerID=salesinfo.CustomerID 
      WHERE salesinfo.CustomerID IS NULL 

JOIN .. La razón por la que es más eficiente es que MySQL no necesita crear una tabla temporal en la memoria para completar esta consulta lógica de dos pasos.

4. Optimizar la consulta de unión

MySQL ejecuta consultas de unión creando y llenando tablas temporales. A menos que realmente desee eliminar filas duplicadas, se recomienda unir todas. La razón es que si no hay una palabra clave "todos", MySQL agregará la opción distinta a la tabla temporal, lo que resultará en la verificación de unicidad de los datos de toda la tabla temporal, lo cual es bastante caro.

Eficiente:

SELECT COL1, COL2, COL3 FROM TABLE WHERE COL1 = 10 
 
UNION ALL 
 
SELECT COL1, COL2, COL3 FROM TABLE WHERE COL3= 'TEST'; 

Ineficiente:

SELECT COL1, COL2, COL3 FROM TABLE WHERE COL1 = 10 
 
UNION 
 
SELECT COL1, COL2, COL3 FROM TABLE WHERE COL3= 'TEST';

5. Divida SQL complejo en varios SQL pequeños para evitar grandes transacciones

  • SQL simple es fácil de usar QUERY CACHE de MySQL;

  • Reducir el tiempo de bloqueo de la tabla, especialmente las tablas que utilizan el motor de almacenamiento MyISAM;

  • Se puede utilizar una CPU de varios núcleos.

6. Utilice truncar en lugar de eliminar

Al eliminar registros en toda la tabla, la operación que utiliza la declaración de eliminación se registrará en el bloque de deshacer y el registro eliminado también se registrará en el binlog. Cuando se confirma que es necesario eliminar toda la tabla, un gran número de binlogs se generarán y se generarán una gran cantidad de bloques de datos de deshacer, no es muy eficiente pero también consume muchos recursos.

Utilice truncar en su lugar, no se registrará ninguna información recuperable y los datos no se pueden recuperar. Por lo tanto, el uso de la operación truncada tiene muy poca ocupación de recursos y un tiempo extremadamente rápido. Además, el uso de truncar puede recuperar el nivel de agua de la mesa, de modo que el valor del campo de autoincremento sea cero.

7. Utilice métodos de paginación razonables para mejorar la eficiencia de la paginación.

Utilice métodos de paginación razonables para mejorar la eficiencia de paginación. Para necesidades de paginación como la visualización, los métodos de paginación adecuados pueden mejorar la eficiencia de la paginación.

Caso 1:

select * from t where thread_id = 10000 and deleted = 0 
   order by gmt_create asc limit 0, 15;

En el ejemplo anterior, todos los campos se ordenan y devuelven de acuerdo con las condiciones del filtro al mismo tiempo. Sobrecarga de acceso a datos = IO de índice + IO de datos de tabla correspondiente a todos los registros de índice. Por lo tanto, cuanto más se invierte este método de escritura, peor será la eficiencia de ejecución y mayor será el tiempo, especialmente cuando la cantidad de datos de la tabla es grande.

Escenarios aplicables: aplicable cuando el conjunto de resultados intermedios es pequeño (menos de 10,000 filas) o las condiciones de la consulta son complicadas (se refieren a varios campos de consulta diferentes o combinaciones de varias tablas).

Caso 2:

select t.* from (select id from t where thread_id = 10000 and deleted = 0
   order by gmt_create asc limit 0, 15) a, t 
      where a.id = t.id; 

El ejemplo anterior debe satisfacer que la clave principal de la tabla t es la columna id, y hay una clave secundaria de índice de cobertura: (thread_id, deleted, gmt_create). Saque el ID de la clave principal según la condición del filtro utilizando el índice de cobertura para ordenar y luego realice la operación de unión para eliminar otros campos. Sobrecarga de acceso a datos = IO de índice + resultado de paginación de índice (15 filas en el ejemplo) correspondiente a la IO de datos de la tabla. Por lo tanto, este método de escritura consume básicamente los mismos recursos y tiempo cada vez que se pasa la página, al igual que se pasa la primera página.

Escenarios aplicables: aplicable cuando los campos de consulta y clasificación (es decir, los campos involucrados en la cláusula where y la cláusula order by) tienen índices de cobertura correspondientes y el conjunto de resultados intermedios es grande.

Cinco, optimización de la construcción de mesas

1. Cree un índice en la tabla, dando prioridad a los campos utilizados por dónde y orden por.

2. Intente utilizar campos numéricos (como género, hombre: 1 mujer: 2). Si el campo contiene solo información numérica, intente no diseñarlo como un tipo de carácter. Esto reducirá el rendimiento de la consulta y la conexión y aumentará el almacenamiento gastos generales.

Esto se debe a que el motor compara cada carácter de la cadena uno por uno cuando procesa consultas y conexiones, y para los tipos numéricos, solo es necesario compararlo una vez.

3. La consulta de tablas con una gran cantidad de datos provocará consultas lentas. La razón principal son demasiadas líneas de escaneo. En este momento, el programa se puede utilizar para consultar por segmento y página, recorrer el bucle y fusionar los resultados para mostrarlos. Para consultar datos de 100000 a 100050, de la siguiente manera:

SELECT * FROM (SELECT ROW_NUMBER() OVER(ORDER BY ID ASC) AS rowid,* 
   FROM infoTab)t WHERE t.rowid > 100000 AND t.rowid <= 100050

4. Utilice varchar / nvarchar en lugar de char / nchar

Utilice varchar / nvarchar en lugar de char / nchar tanto como sea posible, porque el espacio de almacenamiento de los campos de longitud variable es pequeño, lo que puede ahorrar espacio de almacenamiento.En segundo lugar, para las consultas, la eficiencia de búsqueda en un campo relativamente pequeño es obviamente mayor.

No pienses que NULL no necesita espacio. Por ejemplo: tipo char (100). Cuando se crea el campo, el espacio es fijo. Independientemente de si se inserta el valor (también se incluye NULL), ocupará 100 caracteres .Si es un varchar Para tales campos de longitud variable, null no ocupa espacio.

FIN

Amigos a los que les gusta este artículo, hagan clic en la imagen para seguir la cuenta de suscripción y ver más contenido emocionante.

Lectura recomendada:

Supongo que te gusta

Origin blog.csdn.net/qq_39507327/article/details/111399139
Recomendado
Clasificación