Optimización del rendimiento de MYSQL

Escriba un buen SQL de acuerdo con los requisitos y cree índices efectivos. Para lograr un determinado requisito, puede escribirlo de varias maneras. En este momento, tenemos que elegir la forma de escritura más eficiente. En este momento, es necesario comprender la optimización de SQL.

2. Optimización de la estructura de la tabla de la base de datos.

Diseñar la estructura de la tabla según el paradigma de la base de datos.El buen diseño de la estructura de la tabla está directamente relacionado con la escritura de sentencias SQL.

3. Optimización de la configuración del sistema

La mayoría se ejecuta en máquinas Linux, como restricciones en la cantidad de conexiones TCP, restricciones en la cantidad de archivos abiertos y restricciones de seguridad, por lo que debemos optimizar estas configuraciones en consecuencia.

4. Optimización de la configuración del hardware

Elija una CPU adecuada para servicios de bases de datos, IO más rápida y mayor memoria; más CPU no siempre es mejor, algunas versiones de bases de datos tienen limitaciones máximas y las operaciones de IO no reducen el bloqueo.

Nota: En la figura anterior se puede ver que en la pirámide, el costo de la optimización aumenta gradualmente de abajo hacia arriba, mientras que el efecto de la optimización disminuye gradualmente.

Optimización de índices y SQL

Instalación y desinstalación de MySQL (instalación y desinstalación en línea de Linux)

Selección de versión de base de datos

1. Verifique la versión de la base de datos.

select @@version;

preparar datos

URL: https://dev.mysql.com/doc/sakila/en/sakila-installation.html

Los archivos contenidos en el paquete comprimido sakila-db.zip se explican a continuación.

Descargar datos

Los pasos son los que se muestran a continuación.

relación de estructura de tabla

Nota: Esta relación de estructura de tabla se genera mediante herramientas.

Cómo detectar SQL problemático

Cómo abrir el formato de almacenamiento y registro de verificación lenta de MySQL

Compruebe si el registro de verificación lenta está habilitado:

show variables like 'slow_query_log'

show variables like 'slow_query_log'  

//查看是否开启慢查询日志

set global slow_query_log_file=' /usr/share/mysql/sql_log/mysql-slow.log'

//慢查询日志的位置

set global log_queries_not_using_indexes=on;

//开启慢查询日志

set global long_query_time=1;  

//大于1秒钟的数据记录到慢日志中，如果设置为默认0，则会有大量的信息存储在磁盘中，磁盘很容易满掉

Ver información variable de todos los registros.

show variables like '%log%'

mysql> show variables like '%log%';

+-----------------------------------------+------------------------------------+

| Variable_name                           | Value                              |

+-----------------------------------------+------------------------------------+

| back_log                                | 80                                 |

| binlog_cache_size                       | 32768                              |

| binlog_checksum                         | CRC32                              |

| binlog_direct_non_transactional_updates | OFF                                |

| binlog_error_action                     | IGNORE_ERROR                       |

| binlog_format                           | STATEMENT                          |

| binlog_gtid_simple_recovery             | OFF                                |

| binlog_max_flush_queue_time             | 0                                  |

| binlog_order_commits                    | ON                                 |

| binlog_row_image                        | FULL                               |

| binlog_rows_query_log_events            | OFF                                |

| binlog_stmt_cache_size                  | 32768                              |

| binlogging_impossible_mode              | IGNORE_ERROR                       |

| expire_logs_days                        | 0                                  |

| general_log                             | OFF                                |

| general_log_file                        | /var/lib/mysql/mysql-host.log      |

| innodb_api_enable_binlog                | OFF                                |

| innodb_flush_log_at_timeout             | 1                                  |

| innodb_flush_log_at_trx_commit          | 1                                  |

| innodb_locks_unsafe_for_binlog          | OFF                                |

| innodb_log_buffer_size                  | 8388608                            |

| innodb_log_compressed_pages             | ON                                 |

| innodb_log_file_size                    | 50331648                           |

| innodb_log_files_in_group               | 2                                  |

| innodb_log_group_home_dir               | ./                                 |

| innodb_mirrored_log_groups              | 1                                  |

| innodb_online_alter_log_max_size        | 134217728                          |

| innodb_undo_logs                        | 128                                |

| log_bin                                 | OFF                                |

| log_bin_basename                        |                                    |

| log_bin_index                           |                                    |

| log_bin_trust_function_creators         | OFF                                |

| log_bin_use_v1_row_events               | OFF                                |

| log_error                               | /var/log/mysqld.log                |

| log_output                              | FILE                               |

| log_queries_not_using_indexes           | ON                                 |

| log_slave_updates                       | OFF                                |

| log_slow_admin_statements               | OFF                                |

| log_slow_slave_statements               | OFF                                |

| log_throttle_queries_not_using_indexes  | 0                                  |

| log_warnings                            | 1                                  |

| max_binlog_cache_size                   | 18446744073709547520               |

| max_binlog_size                         | 1073741824                         |

| max_binlog_stmt_cache_size              | 18446744073709547520               |

| max_relay_log_size                      | 0                                  |

| relay_log                               |                                    |

| relay_log_basename                      |                                    |

| relay_log_index                         |                                    |

| relay_log_info_file                     | relay-log.info                     |

| relay_log_info_repository               | FILE                               |

| relay_log_purge                         | ON                                 |

| relay_log_recovery                      | OFF                                |

| relay_log_space_limit                   | 0                                  |

| simplified_binlog_gtid_recovery         | OFF                                |

| slow_query_log                          | OFF                                |

| slow_query_log_file                     | /var/lib/mysql/mysql-host-slow.log |

| sql_log_bin                             | ON                                 |

| sql_log_off                             | OFF                                |

| sync_binlog                             | 0                                  |

| sync_relay_log                          | 10000                              |

| sync_relay_log_info                     | 10000                              |

+-----------------------------------------+------------------------------------+

61 rows in set (0.01 sec)

Habilitar registro de verificación lenta:

show variables like 'slow_query_log'  
//查看是否开启慢查询日志
set global slow_query_log_file=' /var/lib/mysql/mysql-host-slow.log '
//慢查询日志的位置
set global log_queries_not_using_indexes=on;
//开启慢查询日志
set global long_query_time=1;  
//大于1秒钟的数据记录到慢日志中，如果设置为默认0，则会有大量的信息存储在磁盘中，磁盘很容易满掉

Verifique si el registro de consultas lentas está habilitado:

En la operación mysql,

show databases;
use sakila;
select * from store;
select * from staff;

Supervise el archivo de registro para ver si está escrito.

cola -50f /var/lib/mysql/mysql-host-slow.log

Formato de almacenamiento de registro de verificación lenta de MySQL

Como se muestra abajo:

ilustrar:

1. # Hora: 180526 1:06:54 ------->Tiempo de ejecución de la consulta

2. # Usuario@Host: raíz[raíz] @ localhost [] Id: 4 ------->Información del host para ejecutar sql

3. # Tiempo_query: 0.000401 Tiempo_bloqueo: 0.000105 Filas_enviadas: 2 Filas_examinadas: 2------->Información de ejecución SQL:

Query_time: tiempo de consulta SQL

Lock_time: tiempo de bloqueo

Rows_sent: número de filas enviadas

Rows_examined: el número de filas escaneadas por el bloqueo

4. SET marca de tiempo = 1527268014;------> tiempo de ejecución de SQL

5. seleccione * del personal;------>contenido de ejecución SQL

Herramienta de análisis de registros de verificación lenta de MySQL ( mysqldumpslow )

introducir

¿Cómo ver el registro de consultas lentas? Si el registro de consultas lentas está activado, se generarán muchos datos, luego podremos analizar el registro, generar un informe de análisis y luego optimizar a través del informe.

uso

A continuación, veamos el uso de esta herramienta:

Nota: En el servidor donde se encuentra la base de datos mysql, no en la línea de comando mysql >

Cómo utilizar esta herramienta:

mysqldumpslow -h

Ver información detallada

Mysqldump lento -v

Vea los 10 registros de consultas lentas principales. Los resultados del análisis de mysqldumpslow son los siguientes:

mysqldumpslow -t 10 /var/lib/mysql/mysql-slow.log

Las dos imágenes de arriba son los resultados del análisis. Cada resultado muestra el tiempo de ejecución, el tiempo de bloqueo, el número de filas enviadas y el número de filas escaneadas.

Esta herramienta es la herramienta más utilizada y se instala instalando mysql. Sin embargo, los resultados estadísticos de esta herramienta son relativamente pocos y los datos sobre nuestro rendimiento de bloqueo de optimización aún son relativamente pequeños.

Herramienta de análisis de registros de consultas lentas de MySQL (pt-query-digest)

Introducción y función

Como excelente DBA de MySQL, también necesita dominar varias herramientas útiles de administración de MySQL, por lo que he estado organizando y buscando algunas herramientas que puedan facilitar la administración de MySQL. En el próximo periodo de tiempo, gran parte de la energía se gastará en buscar estas herramientas.

La gestión del rendimiento siempre ha sido la primera prioridad. La gestión de muchas tareas del DBA no puede ver y no tiene forma de medir el valor. Sin embargo, si un sistema es tan lento como un caracol, el DBA puede restaurar el sistema desde el borde del colapso mediante el monitoreo. y puesta a punto: nos llevarán de vuelta a la era del tren de alta velocidad. El valor y el toque deben ser enormes. (Muchos líderes de empresas creen que si el sistema ya no puede funcionar, necesitan reemplazarlo con una CPU más rápida, una memoria más grande y un almacenamiento más rápido, y esto no es una minoría. Por lo tanto, el valor de un DBA no se ha reflejado y el salario, naturalmente, no será muy alto)

El registro de MySQL es la forma más rápida y directa de rastrear los cuellos de botella en el rendimiento de MySQL. Cuando ocurre un cuello de botella en el rendimiento del sistema, primero debe abrir el registro de consultas lentas y realizar un seguimiento. Durante este período, la administración y visualización del registro de consultas lentas se han Se resolvió dos veces. Después de leer este artículo, descubrí accidentalmente otra herramienta para ver registros de consultas lentas: mk-query-digest. Esta herramienta se conoce como una de las diez herramientas principales que MySQL DBA debe dominar en Internet.

Instalar la herramienta pt-query-digest

Instalación rápida (nota: wget debe instalarse primero)

wget https://www.percona.com/downloads/percona-toolkit/2.2.16/RPM/percona-toolkit-2.2.16-1.noarch.rpm && yum localinstall -y percona-toolkit-2.2.16-1 .norch.rpm

Compruebe si la instalación está completa :

Ingrese: pt-summary en la línea de comando

La pantalla es como se muestra a continuación: ¡la instalación se realizó correctamente! Ingrese [[root@node03 mysql]# pt-query-digest --help]

Introducción al uso de la herramienta:

resumen-pt –ayuda

wget http://percona.com/get/pt-summary

Ver información del servidor

Comando: pt-resumen

Ver información de uso general del disco

Comando: pt-diskstats

Ver información de la base de datos mysql

Instrucción: pt-mysql-summary --user=root --password=123456

Analizar registros de consultas lentas

Comando: pt-query-digest /data/mysql/data/db-3-12-slow.lo

Encuentre la base de datos esclava y el estado de sincronización de mysql

Instrucción: pt-slave-find --host=localhost --user=root --password=123456

Ver información sobre el punto muerto de MySQL

pt-deadlock-logger --user=root --password=123456 localhost

Analice el uso del índice a partir de registros de consultas lentas

uso del índice pt slow_20131009.log

Encuentre índices duplicados en tablas de bases de datos

pt-verificador-de-claves-duplicadas --host=localhost --user=root --password=123456

Ver la sobrecarga de IO activa actual para tablas y archivos mysql

perfil-pt-io

Ver las diferencias entre diferentes archivos de configuración de MySQL

pt-config-diff /etc/my.cnf /etc/my_master.cnf

pt-find encuentra la tabla mysql y ejecuta el comando, el ejemplo es el siguiente

Encuentre tablas de más de 2G en la base de datos:

pt-find --usuario=root --contraseña=123456 --tamaño de tabla +2G

Busque la tabla creada hace 10 días en el motor MyISAM:

pt-find --usuario=root --contraseña=123456 --ctime +10 --motor MyISAM

Ver tamaños de tabla e índice y ordenar

pt-find --user=root --password=123456 --printf "%T\t%D.%N\n" | ordenar -rn

pt-kill mata el proceso mysql que cumple con el estándar

Mostrar consultas que tardan más de 60 segundos

pt-kill --usuario=root --contraseña=123456 --tiempo ocupado 60 --imprimir

Eliminar consultas de más de 60 segundos

pt-kill --usuario=root --contraseña=123456 --tiempo ocupado 60 --kill

Ver autorización de MySQL

1. pt -show-grants --usuario=root --contraseña=123456

2 、pt-show-grants --user=root --password=123456 --separate –revoke

Verificar la integridad de la replicación de la base de datos.

pt-table-checksum --usuario=root --contraseña=123456

apéndice:

Cómo encontrar SQL problemático mediante registros de verificación lentos

SQL con muchas consultas y cada consulta lleva mucho tiempo.

Generalmente son las primeras consultas analizadas por pt-query-digest, esta herramienta puede ver claramente el número y porcentaje de cada SQL ejecutado. El SQL que se ejecuta más veces y representa una mayor proporción

E/S SQL grande

Preste atención al elemento de examen de filas en el análisis de pt-query-digest. Cuantas más filas se escaneen, mayor será el IO.

SQL para errores de índice

Preste atención a la comparación entre el examen de filas y el envío de filas en el análisis pt-query-digest. Significa que la tasa de aciertos del índice de este SQL no es alta, debemos prestar especial atención a este tipo de SQL.

Analizar el plan de ejecución de SQL mediante consulta explicativa

Utilice explicar para consultar el plan de ejecución de SQL

El plan de ejecución de SQL refleja la eficiencia de ejecución de SQL. El método de ejecución específico es el siguiente:

Simplemente agregue la palabra clave explicar delante del SQL ejecutado;

Descripción de cada campo:

1) Cuanto mayor sea el número en la columna de identificación, más rápido se ejecutará. Si los números son iguales, se ejecutarán de arriba a abajo. Si la columna de identificación es nula, significa que se trata de un conjunto de resultados. y no es necesario utilizarlo para realizar consultas.

2) Las columnas select_type comunes incluyen:

R: simple: indica una consulta de selección simple que no requiere operaciones de unión o no contiene subconsultas. Cuando hay una consulta de conexión, la consulta externa es simple y solo hay una

B: primario: una selección que requiere una operación de unión o contiene una subconsulta. El tipo de selección de la consulta de unidad más externa es primario. y solo uno

C: Unión: dos consultas de selección conectadas por unión. La primera consulta es una tabla derivada derivada. Excepto por la primera tabla, el tipo de selección de la segunda tabla y las siguientes es unión.

D: unión dependiente: igual que unión, aparece en unión o unión toda declaración, pero esta consulta se verá afectada por una consulta externa

E: Resultado de la unión: el conjunto de resultados que contiene la unión. En las declaraciones unión y unión todas, debido a que no es necesario participar en la consulta, el campo de identificación es nulo.

F: subconsulta: excepto la subconsulta contenida en la cláusula from, las subconsultas que aparecen en otros lugares pueden ser subconsultas.

G: subconsulta dependiente: similar a la unión dependiente, lo que indica que la consulta de esta subconsulta se verá afectada por la consulta de la tabla externa

H: derivada: la subconsulta que aparece en la cláusula from también se denomina tabla derivada. En otras bases de datos, se puede denominar vista en línea o selección anidada.

3) mesa

El nombre de la tabla de consulta mostrada. Si la consulta utiliza un alias, entonces el alias se muestra aquí. Si no implica la operación de la tabla de datos, entonces esto se muestra como nulo. Si se muestra como <N derivado> encerrado en paréntesis angulares, significa que esta es una tabla temporal, la siguiente N es la identificación en el plan de ejecución, lo que indica que los resultados provienen de esta consulta. Si es <union M,N> encerrado entre corchetes angulares, es similar a <derived N> y también es una tabla temporal, lo que indica que el resultado proviene del conjunto de resultados con id M,N de la consulta de unión.

4）tipo

De mejor a peor: system, const, eq_ref, ref, fulltext, ref_or_null, unique_subquery, index_subquery, range, index_merge, index, ALL, excepto todos, otros tipos pueden usar index, excepto index_merge, other Solo se puede usar un índice para tipo

R: sistema: solo hay una fila de datos en la tabla o es una tabla vacía y solo se puede usar para tablas myisam y de memoria. Si se trata de una tabla del motor Innodb, la columna de tipo en este caso suele ser all o index.

B: const: cuando se utiliza un índice único o una clave primaria, el registro devuelto debe ser una condición donde equivalente de 1 fila de registros, generalmente el tipo es constante. Otras bases de datos también se denominan escaneos de índice únicos.

C: eq_ref: Aparece en el plan de consulta para estar conectado a dos tablas. La tabla del controlador solo devuelve una fila de datos, y esta fila de datos es la clave principal o índice único de la segunda tabla, y no debe ser nula. El índice único y la clave principal son columnas múltiples, eq_ref solo aparecerá cuando todas las columnas se usen para comparar.

D: ref: no requiere el orden de conexión como eq_ref, y no hay requisitos de clave primaria ni índice único. Puede ocurrir siempre que se utilicen condiciones iguales para la recuperación y las búsquedas de igualdad con índices auxiliares sean comunes. O en una clave primaria de varias columnas o un índice único, también puede ocurrir el uso de columnas distintas a la primera columna como una búsqueda de valor igual. En resumen, puede ocurrir una búsqueda de valor igual donde los datos devueltos no son únicos.

E: texto completo: recuperación del índice de texto completo. Tenga en cuenta que la prioridad del índice de texto completo es muy alta. Si el índice de texto completo y el índice ordinario existen al mismo tiempo, MySQL dará prioridad al texto completo. índice independientemente del costo.

F: ref_or_null: Similar al método ref, excepto que se agrega la comparación de valores nulos. En realidad no se usa mucho.

G: subconsulta_única: se utiliza para subconsultas en forma en dónde. La subconsulta devuelve valores únicos sin valores duplicados.

H: index_subquery: se utiliza para subconsultas en forma que utilizan índices auxiliares o en listas constantes. La subconsulta puede devolver valores duplicados y el índice se puede utilizar para deduplicar la subconsulta.

I: rango: escaneo de rango de índice, comúnmente utilizado en consultas que utilizan operadores como >, <, es nulo, entre, en, me gusta, etc.

J: index_merge: indica que la consulta usa más de dos índices y finalmente toma la intersección o unión. Las condiciones comunes y yo usan índices diferentes. La clasificación oficial es después de ref_or_null, pero de hecho, debido a que es necesario leer todos los índices, Es posible que el rendimiento no sea tan bueno como el rango la mayor parte del tiempo.

K: índice: escaneo completo de la tabla del índice, escanea el índice de principio a fin. Es común usar columnas de índice para procesar consultas que no necesitan leer archivos de datos y usar consultas de clasificación o agrupación de índices.

L: todo: esto es para escanear el archivo de datos en toda la tabla y luego filtrarlo en la capa del servidor para devolver registros que cumplan con los requisitos.

5）posibles_claves

Los índices que puede utilizar la consulta se enumerarán aquí.

6) clave

Consulta el índice realmente utilizado. Cuando select_type es index_merge, pueden aparecer más de dos índices aquí. Para otros select_types, solo aparecerá uno aquí.

7) clave_len

La longitud del índice utilizada para procesar consultas. Si es un índice de una sola columna, se incluye toda la longitud del índice. Si es un índice de varias columnas, es posible que la consulta no pueda utilizar todas las columnas. Específicamente, cuántas columnas Se utilizan índices, aquí se calculará. Las columnas no utilizadas no se calcularán aquí. Preste atención al valor de esta columna y calcule la longitud total de su índice de varias columnas para saber si se utilizan todas las columnas. Cabe señalar que los índices utilizados por la función ICP de MySQL no se contarán. Además, key_len solo calcula la longitud del índice utilizado en la condición donde, e incluso si el índice se utiliza para ordenar y agrupar, no se calculará en key_len.

8）referencia

Si es una consulta equivalente constante, aquí se mostrará const. Si es una consulta de conexión, el plan de ejecución de la tabla conducida mostrará los campos asociados de la tabla conducida. Si la condición usa una expresión o función, o la condición La columna tiene un error interno. Conversión implícita, que puede aparecer como función aquí.

9) filas

Aquí está el número estimado de líneas de escaneo en el plan de ejecución, no un valor exacto.

10）extra

Esta columna puede mostrar mucha información, hay docenas de ellas, las más utilizadas son

R: distinto: la palabra clave distinta se utiliza en la parte de selección

B: no se utilizan tablas: consulta sin cláusula from o consulta dual From

C: Utilice la subconsulta de formulario not in() o la consulta de unión del operador no existe. Esto se denomina anti-unión. Es decir, una consulta de combinación general consulta primero la tabla interna y luego la tabla externa, mientras que una consulta anti-unión consulta primero la tabla externa y luego la tabla interna.

D: uso de clasificación de archivos: esto ocurre cuando el índice no se puede utilizar durante la clasificación. Comúnmente visto en declaraciones ordenadas por y agrupadas por

E: uso del índice: no es necesario volver a consultar la tabla al realizar la consulta, los datos consultados se pueden obtener directamente a través del índice.

F: uso del búfer de unión (bucle anidado de bloques), uso del búfer de unión (acceso de clave por lotes): las versiones posteriores a 5.6.x optimizan las funciones BNL y BKA de consultas relacionadas. El objetivo principal es reducir la cantidad de bucles en la tabla interna y escanear la consulta secuencialmente.

G: usando sort_union, usando_union, usando intersect, usando sort_intersection:

usando intersect: Al expresar las condiciones de cada índice usando y, esta información indica que la intersección se obtiene a partir de los resultados del procesamiento.

usando unión: Indica que al usar o conectar las condiciones de cada índice, esta información indica que la unión se obtiene de los resultados del procesamiento.

usando sort_union y usando sort_intersection: son similares a los dos anteriores, excepto que aparecen cuando se usa y y o para consultar una gran cantidad de información. Primero se consulta la clave principal y luego los registros se leen y devuelven después de ordenar y fusionar.

H: usando temporal: Indica que se usa una tabla temporal para almacenar resultados intermedios. Las tablas temporales pueden ser tablas temporales de memoria y tablas temporales de disco. No se pueden ver en el plan de ejecución. Debe verificar las variables de estado, used_tmp_table y used_tmp_disk_table para verlas.

I: usar dónde: indica que no todos los registros devueltos por el motor de almacenamiento cumplen con las condiciones de la consulta y deben filtrarse en la capa del servidor. Las condiciones de consulta se dividen en condiciones de restricción y condiciones de inspección. Antes de 5.6, el motor de almacenamiento solo podía escanear y devolver datos de acuerdo con las condiciones de restricción, y luego la capa del servidor filtraba de acuerdo con las condiciones de inspección y devolvía datos que realmente cumplieran con la consulta. Después de 5.6.x, se admite la función ICP y las condiciones de verificación se pueden enviar a la capa del motor de almacenamiento. Los datos que no cumplan con las condiciones y restricciones de verificación no se leerán directamente, lo que reduce en gran medida la cantidad de registros escaneados por el motor de almacenamiento. La columna adicional muestra el uso de la condición de índice.

J: firstmatch(tb_name): una de las nuevas características de optimización de subconsultas introducidas en 5.6.x. Es común en subconsultas que contienen cláusulas de tipo in() en donde. Si la cantidad de datos en la tabla interna es relativamente grande, esto puede ocurrir.

K: Loosescan (m..n): una de las nuevas características de optimización de subconsultas introducidas después de 5.6.x. En la subconsulta de tipo in(), esto puede ocurrir cuando la subconsulta devuelve registros duplicados.

Además de estos, existen muchas bibliotecas de diccionarios de datos de consulta. Durante el proceso del plan de ejecución, se encuentran algunos mensajes que indican que los resultados no existen.

11）filtrado

Esta columna aparecerá cuando se utilice la explicación extendida. Las versiones posteriores a la 5.7 tienen este campo de forma predeterminada, por lo que no es necesario utilizar la explicación extendida. Este campo indica la proporción de los registros restantes que satisfacen la consulta después de que los datos devueltos por el motor de almacenamiento se filtran en la capa del servidor. Tenga en cuenta que es un porcentaje, no un número específico de registros.

Imágenes adjuntas:

Casos de optimización para consultas lentas específicas

Optimización de la función Max()

Propósito: Consultar la hora del último pago - optimizar la función max()

Declaración:

select max(payment_date) from payment;

Plan de IMPLEMENTACION:

explain select max(payment_date) from payment;

Puede ver que el plan de ejecución mostrado no es muy eficiente y puede ralentizar la eficiencia del servidor, ¿cómo se puede optimizar?

Crear índice

create index inx_paydate on payment(payment_date);

El índice se opera secuencialmente y no es necesario escanear la tabla, por lo que la eficiencia de ejecución será relativamente constante.

Optimización de la función Count()

Requisito: verificar simultáneamente la cantidad de películas en 2006 y 2007 en un SQL

Camino equivocado:

Declaración:

select count(release_year='2006' or release_year='2007') from film;

No puedo decir cuáles fueron las cifras en 2006 y 2007.

 select count(*) from film where release_year='2006' or release_year='2007';

Forma correcta de escribir:

select count(release_year='2006' or null) as '06films',count(release_year='2007' or null) as '07films' from film;

Diferencia: contar(*) y contar(id)

Crear tabla e insertar declaración

 create table t(id int);

 insert into t values(1),(2),(null);

Count（*）：select count(*)from t;

Count（id）：select count(id)from t;

ilustrar:

Count(id) es un valor que no contiene nulo

Count(*) es un valor que contiene nulo

Optimización de subconsultas

La subconsulta es un método que utilizamos a menudo en el proceso de desarrollo. En circunstancias normales, la subconsulta debe optimizarse en una consulta de unión. Sin embargo, durante la optimización, debe prestar atención a si la clave asociada tiene una relación de uno a muchos. y preste atención a los datos duplicados.

Ver la tabla t que creamos

show create table t;

A continuación creamos una tabla t1.

create table t1(tid int);

e inserte un dato

Necesitamos realizar una subconsulta, el requisito es: consultar todos los datos de la tabla t cuyo id es tid en la tabla t1;

select * from t where t.id in (select t1.tid from t1);

A continuación usamos la operación de unión para realizar la operación.

select id from t join t1 on t.id =t1.tid;

A juzgar por los resultados anteriores, los resultados de la consulta son consistentes, por lo que optimizamos la subconsulta en una operación de unión.

A continuación, insertamos otro dato en la tabla t1.

insert into t1 values (1);

select * from t1;

En este caso, si usamos subconsulta para consultar, el resultado devuelto es el que se muestra a continuación:

Si utiliza el método de unión para buscar, como se muestra en la siguiente figura:

En este caso, existe una relación de uno a muchos y habrá duplicación de datos. Para evitar la duplicación de datos, debemos utilizar la palabra clave distinta para realizar operaciones de deduplicación.

select distinct id from t join t1 on t.id =t1.tid;

Nota: Esta relación de uno a muchos es un error que encontramos durante el proceso de desarrollo: se produce la duplicación de datos y todos deben prestarle atención.

Ejemplo: Consultar todas las películas protagonizadas por Sandra:

explain select title,release_year,length

 from film

 where film_id in (

 select film_id from film_actor where actor_id in (

 select actor_id from actor where first_name='sandra'));

Optimización de grupo por

Es mejor usar columnas de la misma tabla,

Requisitos: El número de películas en las que ha participado cada actor - (lista de películas y lista de reparto)

explain select actor.first_name,actor.last_name,count(*)

from sakila.film_actor

inner join sakila.actor using(actor_id)

group by film_actor.actor_id;

SQL optimizado:

explain select actor.first_name,actor.last_name,c.cnt

from sakila.actor inner join (

select actor_id,count(*) as cnt from sakila.film_actor group by actor_id

)as c using(actor_id);

Nota: A juzgar por el plan de ejecución anterior, este método optimizado no utiliza archivos temporales ni clasificación de archivos , sino que utiliza índices. La eficiencia de la consulta es muy alta.

En este momento, los datos en nuestra tabla son relativamente grandes, lo que ocupará muchas operaciones de IO, optimizará la eficiencia de la ejecución de SQL y ahorrará recursos del servidor, por lo que debemos optimizar.

Aviso:

1. La función de usar palabras clave en mysql : es decir , para usar usando, la tabla a y la tabla b deben tener las mismas columnas .

2. Cuando usamos Join para realizar consultas conjuntas en varias tablas, generalmente usamos On para establecer la relación entre las dos tablas. De hecho, hay una palabra clave más conveniente: Usar.

3. Si los nombres de los campos asociados de las dos tablas son iguales, puede usar Usando para establecer la relación, que es concisa y clara.

Optimización de la consulta de límite

El límite se usa a menudo para el procesamiento de paginación y la duración se usa con la cláusula ordenar por, por lo que la mayoría de las veces se usa Filesorts, lo que causará muchos problemas de IO.

ejemplo:

Requisito: consultar el ID de la película y la información de descripción, ordenar según el tema y recuperar 5 datos a partir del número de serie 50.

select film_id,description from sakila.film order by title limit 50,5;

Resultado de la ejecución:

Consulta su plan de ejecución:

¿Qué método de optimización debemos utilizar para esta operación?

Paso de optimización 1:

Utilice columnas indexadas o claves primarias para realizar operaciones de orden, porque como todos sabemos, innodb ordena según el orden lógico de las claves primarias. Se pueden evitar muchas operaciones de IO.

select film_id,description from sakila.film order by film_id limit 50,5;

Consulta el plan de ejecución.

Entonces, si obtenemos 5 registros a partir de la fila 500, ¿cómo será el plan de ejecución?

explain select film_id,description from sakila.film order by film_id limit 500,5\G

A medida que pasamos la página, la operación IO se hará cada vez más grande. Si una tabla tiene decenas de millones de filas de datos, el cambio de página será cada vez más lento, por lo que debemos optimizarlo aún más.

Paso 2 de optimización: registre la clave principal devuelta la última vez y utilice el filtrado de clave principal en la siguiente consulta. ( Nota: esto evita escanear demasiados registros cuando la cantidad de datos es grande )

El último límite fue 50,5, por lo que debemos utilizar el último valor del registro de índice en este proceso de optimización.

select film_id,description from sakila.film  where film_id >55 and film_id<=60 order by film_id limit 1,5;

Ver el plan de ejecución:

Conclusión: el número de líneas de escaneo permanece sin cambios, el plan de ejecución es muy fijo y la eficiencia también es muy fija.

Precauciones:

Las claves primarias deben estar ordenadas de forma secuencial y continua. Si hay una determinada columna o varias columnas en medio de la clave primaria, habrá menos de 5 filas de datos listados; si no es continua, cree una columna adicional index_id para asegúrese de que esta columna de datos desee aumentarla automáticamente, simplemente agregue un índice.

Optimización del índice

1. ¿Qué es un índice?

El índice es equivalente al índice de un libro. Puede encontrar rápidamente el contenido requerido según los números de página del índice.

La base de datos utiliza un índice para encontrar un valor específico y luego apunta hacia adelante para encontrar la fila que contiene ese valor. Cree un índice en la tabla, luego busque el valor del índice que cumpla con las condiciones de consulta en el índice y, finalmente, encuentre rápidamente el registro correspondiente en la tabla a través del ROWID (equivalente al número de página) guardado en el índice. El establecimiento de un índice es un campo relativamente direccional en la tabla, que es equivalente a un directorio. Por ejemplo, el código de área administrativa. Los códigos de área administrativa en la misma región son todos iguales. Luego agregue un índice a esta columna para evite escaneos repetidos ¡Logre el propósito de optimización!

2. Cómo crear un índice

Se pueden crear índices al ejecutar la instrucción CREATE TABLE, o se pueden usar CREATE INDEX o ALTER TABLE solos para agregar índices a la tabla.

1 、ALTERAR TABLA

ALTER TABLE se utiliza para crear un índice normal, un índice ÚNICO o un índice PRIMARY KEY.

ALTER TABLE table_name ADD INDEX index_name (column_list)

ALTER TABLE table_name ADD UNIQUE (column_list)

ALTER TABLE table_name ADD PRIMARY KEY (column_list)

Nota: nombre_tabla es el nombre de la tabla que se va a indexar, lista_columnas indica qué columnas indexar y, si hay varias columnas, sepárelas con comas. El nombre del índice index_name es opcional. De forma predeterminada, MySQL asignará un nombre basado en la primera columna del índice. Además, ALTER TABLE permite modificar varias tablas en una sola declaración, por lo que se pueden crear varios índices al mismo tiempo.

2. CREAR ÍNDICE

CREATE INDEX puede agregar índices ordinarios o índices ÚNICOS a la tabla.

CREATE INDEX index_name ON table_name (column_list)

CREATE UNIQUE INDEX index_name ON table_name (column_list)

Nota: nombre_tabla, nombre_índice y lista_columnas tienen el mismo significado que en la instrucción ALTER TABLE y el nombre del índice no es opcional. Además, no puede utilizar la instrucción CREATE INDEX para crear un índice PRIMARY KEY.

3. Tipo de índice

Cuando crea un índice, puede especificar si el índice puede contener valores duplicados. Si no se incluye, el índice debe crearse como CLAVE PRIMARIA o índice ÚNICO. Para un índice único de una sola columna, esto garantiza que la columna única no contenga valores duplicados. Para índices únicos de varias columnas, se garantiza que la combinación de múltiples valores no se repetirá.

Los índices PRIMARY KEY son muy similares a los índices UNIQUE.

De hecho, un índice PRIMARY KEY es simplemente un índice ÚNICO con el nombre PRIMARY. Esto significa que una tabla sólo puede contener una CLAVE PRIMARIA, porque es imposible tener dos índices con el mismo nombre en una tabla.

La siguiente declaración SQL agrega un índice PRIMARY KEY en sid a la tabla de estudiantes.

ALTER TABLE students ADD PRIMARY KEY (sid)

4. Eliminar índice

Los índices se pueden eliminar utilizando la instrucción ALTER TABLE o DROP INDEX. De manera similar a la declaración CREATE INDEX, DROP INDEX se puede procesar como una declaración dentro de ALTER TABLE. La sintaxis es la siguiente.

DROP INDEX index_name ON talbe_name

ALTER TABLE table_name DROP INDEX index_name

ALTER TABLE table_name DROP PRIMARY KEY

Entre ellas, las dos primeras declaraciones son equivalentes y se elimina el índice nombre_índice en nombre_tabla.

La tercera declaración solo se usa al eliminar el índice PRIMARY KEY, porque una tabla solo puede tener un índice PRIMARY KEY, por lo que no es necesario especificar el nombre del índice. Si no se crea ningún índice PRIMARY KEY pero la tabla tiene uno o más índices ÚNICOS, MySQL descarta el primer índice ÚNICO.

Si se elimina una columna de una tabla, el índice se verá afectado. Para un índice de varias columnas, si se elimina una de las columnas, la columna también se eliminará del índice. Si elimina todas las columnas que componen el índice, se eliminará todo el índice.

5. Ver índice

show index from tblname;

show keys from tblname;

6. ¿En qué circunstancias se utilizan los índices?

1. La clave principal de la tabla.

2. Cree automáticamente un índice único.

3. Restricciones únicas en los campos de la tabla.

4. Campos para consulta condicional directa (campos utilizados para restricciones condicionales en SQL)

5. Campos asociados a otras tablas de la consulta.

6. Los campos ordenados en la consulta (si se accede a los campos ordenados a través del índice, la velocidad de clasificación mejorará enormemente)

7. Campos para estadísticas o estadísticas de grupo en consultas

8. Los registros de la tabla son muy pocos (si una tabla solo tiene 5 registros y se usa un índice para acceder a los registros, primero se debe acceder a la tabla de índice y luego a la tabla de datos a través de la tabla de índice. Generalmente, la tabla de índice y la tabla de datos no están en el mismo bloque de datos)

9. Tablas que se insertan, eliminan o modifican con frecuencia (para algunas tablas comerciales procesadas con frecuencia, los índices deben reducirse tanto como sea posible si las consultas lo permiten)

10. Campos de tabla con datos repetidos y distribución uniforme (si una tabla tiene 100.000 filas de registros y hay un campo A que solo tiene dos valores: T y F, y la probabilidad de distribución de cada valor es aproximadamente del 50%, entonces para este tipo de tabla A La creación de índices en los campos generalmente no mejora la velocidad de consulta de la base de datos).

11. Campos de tabla que a menudo se consultan junto con el campo principal pero que tienen muchos valores de índice de campo principal

12. Cosas que hacer al indexar decenas de millones de bases de datos MySQL y cómo mejorar el rendimiento

3. Cómo seleccionar columnas apropiadas para crear índices

1. Agregue índices a las columnas de la cláusula donde, cláusula agrupar por cláusula, ordenar por cláusula y cláusula on

2. Cuanto más pequeño sea el campo de índice, mejor (debido a que la unidad de almacenamiento de datos de la base de datos se basa en "páginas", cuantos más datos se almacenen, mayor será el IO)

3. Las columnas con gran dispersión se colocan delante del índice de unión.

ejemplo:

select * from payment where staff_id =2 and customer_id =584;

Aviso:

¿Es mejor el índice ( staff_id , customer_id ) o el índice ( customer_id , staff_id )?

Entonces, ¿cómo verificamos la dispersión?

A. Veamos primero la estructura de la tabla.

desc payment;

B. Verifique el número de ID diferentes en estos dos campos respectivamente, cuanto mayor sea el número, mayor será el grado de dispersión: por lo tanto, se puede ver en la siguiente figura: customer_id tiene un mayor grado de dispersión.

Conclusión: dado que customer_id es muy discreto, es mejor utilizar el índice ( customer_id , staff_id )

C. índice conjunto mysql

①Reglas de nomenclatura: nombre de la tabla_nombre del campo

1. Los campos que deben indexarse deben estar en la condición donde

2. No es necesario indexar los campos con una pequeña cantidad de datos.

3. Si hay una relación OR en la condición donde, la indexación no funcionará.

4. Cumplir con el principio más a la izquierda

②¿Qué es un índice conjunto?

Un índice de dos o más columnas se denomina índice conjunto, también conocido como índice compuesto.
El uso de columnas adicionales en un índice le permite limitar el alcance de su búsqueda, pero usar un índice con dos columnas es diferente a usar dos índices separados. La estructura de un índice compuesto es similar a una guía telefónica, donde el nombre de una persona se compone de un nombre y un apellido. La guía telefónica primero se ordena por pares de apellidos y luego por nombre para las personas con el mismo apellido. . Una guía telefónica es muy útil si conoce su apellido, más útil si conoce tanto su nombre como su apellido, pero inútil si solo conoce su nombre pero no su apellido.

Por lo tanto, al crear un índice compuesto, se debe considerar cuidadosamente el orden de las columnas. Los índices compuestos son útiles cuando se busca en todas las columnas del índice o solo en las primeras columnas; no son útiles cuando se busca en ninguna columna posterior.

4. Métodos para la optimización del índice SQL.

1. Mantenimiento y optimización de índices (índices duplicados y redundantes)

Aumentar los índices será beneficioso para la eficiencia de las consultas, pero reducirá la eficiencia de inserción, actualización y eliminación. Sin embargo, este no suele ser el caso. Demasiados índices no solo afectarán la eficiencia del uso, sino que también afectarán la eficiencia de las consultas. se debe a la consulta de la base de datos. Al analizar, primero debe elegir qué índice usar para la consulta. Si hay demasiados índices, el proceso de análisis será más lento, lo que también reducirá la eficiencia de la consulta. Por lo tanto, necesitamos saber cómo aumentar y, a veces, mantener y eliminar los innecesarios.

2. Cómo encontrar índices duplicados y redundantes

Índice duplicado:

Los índices duplicados se refieren a índices del mismo tipo creados en las mismas columnas en el mismo orden. Los índices de las columnas de clave principal e ID en la siguiente tabla son índices duplicados.

create table test(

id int not null primary key,

name varchar(10) not null,

title varchar(50) not null,

unique(id)

)engine=innodb;

Índice redundante:

Un índice redundante se refiere a un índice con la misma columna de prefijo en varios índices, o un índice que contiene la clave principal en un índice conjunto. En el siguiente ejemplo, la clave (nombre, identificación) es un índice redundante.

create table test(

id int not null primary key,

name varchar(10) not null,

title varchar(50) not null,

key(name,id)

)engine=innodb;

Nota: Para innodb, la clave principal en realidad se incluirá detrás de cada índice. En este momento, el índice conjunto que establecimos incluye artificialmente la clave principal, por lo que es un índice redundante en este momento.

3. Cómo encontrar índices duplicados

Herramientas: utilice la herramienta pt-duplicate-key-checker para comprobar si hay índices duplicados y redundantes

pt-verificador-de-claves-duplicadas -uroot -padmin -h 127.0.0.1

4. Métodos de mantenimiento del índice.

Debido a cambios comerciales, algunos índices ya no son necesarios y deben eliminarse.

En mysql, el uso del índice solo se puede analizar mediante registros de consultas lentos y la herramienta pt-index-usage;

uso-índice-pt -uroot -padmin /var/lib/mysql/mysql-host-slow.lo

Adjunto: https://www.percona.com/downloads/

5. Cosas a tener en cuenta

Los índices MySql bien diseñados pueden hacer que su base de datos vuele y mejorar en gran medida la eficiencia de la base de datos. Hay algunos puntos a tener en cuenta al diseñar índices MySql:

1. Crea un índice

Para aplicaciones donde dominan las consultas, los índices son particularmente importantes. Muchas veces los problemas de rendimiento se deben simplemente a que nos olvidamos de agregar un índice o no agregamos un índice más efectivo. Si no hay índice, se realizará un escaneo completo de la tabla para encontrar incluso un dato específico. Si la cantidad de datos en una tabla es grande y hay pocos resultados calificados, entonces no agregar un índice causará una degradación fatal del rendimiento. . .

Pero no es necesario crear un índice en cada situación. Por ejemplo, el género puede tener solo dos valores. Crear un índice no sólo no tiene ninguna ventaja, sino que también afecta la velocidad de actualización. Esto se llama sobreindexación.

2. Índice compuesto

Por ejemplo, hay una declaración como esta: seleccione * de los usuarios donde área='beijing' y edad=22;

Si creamos un índice único para el área y la edad respectivamente, dado que la consulta MySQL solo puede usar un índice a la vez, aunque esto ha mejorado la eficiencia del respectivamente , Crear un índice compuesto en la columna brindará una mayor eficiencia. Si creamos un índice compuesto de (área, edad, salario), en realidad es equivalente a crear tres índices (área, edad, salario), (área, edad) y (área), lo que se denomina la mejor característica del prefijo izquierdo. .

Por lo tanto, cuando creamos un índice compuesto, debemos colocar las columnas más utilizadas como restricciones a la izquierda, en orden descendente.

3. El índice no contendrá columnas con valores NULL.

Mientras una columna contenga un valor NULL, no se incluirá en el índice. Mientras una columna en el índice compuesto contenga un valor NULL, esta columna no será válida para el índice compuesto. Por lo tanto, al diseñar la base de datos, no debemos permitir que el valor predeterminado del campo sea NULL.

4. Utilice índices cortos

Para indexar columnas de cadena, se debe especificar una longitud de prefijo si es posible. Por ejemplo, si tiene una columna CHAR(255), no indexe la columna completa si la mayoría de los valores son únicos dentro de los primeros 10 o 20 caracteres. Los índices cortos no sólo mejoran la velocidad de las consultas sino que también ahorran espacio en disco y operaciones de E/S.

5. Problema del índice de clasificación

Las consultas MySQL solo usan un índice, por lo que si se ha usado un índice en la cláusula donde, las columnas ordenadas por no usarán el índice. Por lo tanto, no utilice operaciones de clasificación cuando la clasificación predeterminada de la base de datos pueda cumplir con los requisitos; trate de no incluir la clasificación de varias columnas. Si es necesario, es mejor crear índices compuestos para estas columnas.

6. Operación de declaración similar

En circunstancias normales, se desaconseja el uso de operaciones similares . Si es necesario utilizarlas, cómo utilizarlas también es un problema. Como “%aaa%” no usará el índice pero como “aaa%” sí lo usará.

7. No realice operaciones en columnas

seleccione * de los usuarios donde

AÑO(añadir fecha)

8. No utilizar NO EN funcionamiento

Las operaciones NOT IN no utilizarán el índice y realizarán un escaneo completo de la tabla. NO EN puede ser reemplazado por NO EXISTE