En los primeros trabajos, no había suficiente diseño. En la actualidad, los datos de la tabla de registro son 2000w y no hay un índice efectivo. El rendimiento es paginación lenta y extracciones de consultas difusas.
En el negocio actual, habrá más operaciones de escritura que operaciones de lectura, y de vez en cuando, encontraremos demasiadas conexiones de datos ocupadas por SQL lento, lo que dará como resultado que las operaciones de escritura no puedan continuar normalmente. Como la tabla de registro tiene datos obvios de frío y calor, considere usar la tabla de partición de datos para resolver el problema de las operaciones de lectura lenta
El siguiente es un registro de la resolución del problema:
1 datos calientes separados
Particione la tabla de registros para reducir el alcance del filtrado de datos.
Aquí elijo el campo de tiempo create_time [TIMESTAMP]
ALTER TABLE record PARTITION by RANGE(UNIX_TIMESTAMP(create_time))
(
PARTITION p1 VALUES LESS THAN ( UNIX_TIMESTAMP('2020-01-01 00:00:00') ),
PARTITION p2 VALUES LESS THAN ( UNIX_TIMESTAMP('2020-02-01 00:00:00') ),
PARTITION p3 VALUES LESS THAN ( UNIX_TIMESTAMP('2020-03-01 00:00:00') ),
PARTITION p4 VALUES LESS THAN ( UNIX_TIMESTAMP('2020-04-01 00:00:00') ),
PARTITION p5 VALUES LESS THAN ( UNIX_TIMESTAMP('2020-05-01 00:00:00') ),
PARTITION p6 VALUES LESS THAN ( UNIX_TIMESTAMP('2020-06-01 00:00:00') ),
PARTITION p7 VALUES LESS THAN ( UNIX_TIMESTAMP('2020-07-01 00:00:00') ),
PARTITION p8 VALUES LESS THAN ( UNIX_TIMESTAMP('2020-08-01 00:00:00') ),
PARTITION p9 VALUES LESS THAN ( UNIX_TIMESTAMP('2020-09-01 00:00:00') ),
PARTITION p10 VALUES LESS THAN (UNIX_TIMESTAMP('2020-10-01 00:00:00') )
)
Aquí hay algunos errores comunes
- Una CLAVE PRIMARIA debe incluir todas las columnas en la función de partición de la tabla
- Un ÍNDICE ÚNICO debe incluir todas las columnas en la función de partición de la tabla
Significa que cada índice único en la tabla debe estar en la expresión de la tabla de partición. Si elijo create_time como el campo de partición, entonces este campo debe ser un índice único. [CLAVE PRIMARIA o ÍNDICE ÚNICO]
Por lo tanto, elimine la CLAVE PRIMARIA original [ID de clave primaria] para establecer una clave primaria conjunta
ALTER TABLE record DROP PRIMARY KEY, ADD PRIMARY KEY(id,create_time);
Use el siguiente comando para ver el número de registros en cada partición
SELECT PARTITION_NAME,TABLE_ROWS FROM INFORMATION_SCHEMA.PARTITIONS WHERE TABLE_NAME = 'record';
Analice SQL para determinar si la consulta distingue particiones
EXPLAIN PARTITIONS SELECT id,create_time FROM table_name WHERE create_time> '2020-03-01 00:00:00' AND create_time< NOW()
La consulta puede distinguir particiones, ya no es una consulta de tabla completa y se logra el objetivo inicial de optimización.
2 Optimizar la eficiencia de la consulta
El negocio implica operaciones de paginación, la sintaxis de paginación más común incluye 2 SQL
- Obtenga el número total de registros
SELECT COUNT(*) - Paginación de registros
SELECT * FROM table_name WHERE xxxxxxx LIMIT n , m
Después de usar la tabla de partición, solo reduce el rango de filtrado de datos [la tabla de datos de 2000w solo usa la partición de los últimos 2 meses, el volumen de datos se reduce a 300w], y la eficiencia de la consulta aumenta en un 70% [45s-> 15s] La consulta toma 10s Lo anterior no resuelve completamente el problema.
2.1 Elija el motor de almacenamiento adecuado
Bajo el motor de almacenamiento InnoDB, COUNT (*) y LIMIT se vuelven extremadamente largos a medida que aumentan los datos de la tabla.
El motor MYISAM es muy rápido, pero no admite bloqueos de nivel de fila. La operación de lectura es un bloqueo compartido, la operación de escritura es un bloqueo exclusivo y admite inserciones concurrentes. En el caso de una presión de escritura excesiva, puede encontrar una situación de bloqueo de la tabla. .
Utilice InnoDB bajo consideración integral
2.2 SQL y ajuste comercial
Hice algunas compensaciones en los negocios, eliminé la última página de paginación e ingresé un número de página personalizado, dejando solo la página hacia arriba y hacia abajo y las últimas páginas para saltar. [Consulte 58 Página de la misma ciudad]
Esto es similar a la consulta del cursor [scroll] en ES. La cooperación de front-end y back-end se completa. La consulta página por página necesita conocer el cursor actual, es decir, la ID de la clave principal, la página anterior y el tamaño de página siguiente.
SELECT * FROM table_name WHERE id > scroll and id < scroll + pageSize
También he visto otra solución de optimización de SQL, que solo necesita ser completada por el back-end, y la eficiencia es relativamente baja. Hay un problema de límite demasiado grande
SELECT * FROM table_name where id >= (SELECT id FROM table_name LIMIT (pageNo-1) * pageSize, 1) LIMIT pageSize
2.3 Ajuste del índice
Cada partición de la tabla particionada se indexa y almacena de forma independiente, la tabla de registro se relaciona con la consulta y el campo de consulta se indexa.
Agregar índice de nombre de registro: CREATE INDEX index_name ON table_name (table_field)
final query SQL: SELECT id, name, create_time FROM table_name WHERE table_field like 'xxxx%' AND create_time> '2020-03-01 00:00:00' AND create_time <NOW ()
analiza SQL: usando Explain, se encuentra que la consulta de índice y el tiempo de paginación están entre 0.01-0.04, que básicamente cumple con los requisitos.
Lo anterior es la optimización de tablas de bases de datos grandes usando tablas particionadas. También hay algunos compromisos y limitaciones comerciales. Por ejemplo, para alcanzar el índice como consulta, la consulta debe coincidir de adelante hacia atrás, y la paginación no puede saltar a la página especificada.
Si no desea comprometer el negocio, puede usar ES para paginación, base de datos para consultas básicas o usar Sphinx para búsqueda de texto completo.
La complejidad del desarrollo empresarial, la precisión de los datos y la puntualidad de los tres son generalmente solo dos. En diferentes situaciones de negocios, tome diferentes decisiones, el benevolente ve el benevolente ve la sabiduría.