En nuestro entorno de producción existe una tabla: courier_consume_fail_message, que almacena los datos de consumo de mensajes fallidos, al inicio del diseño se estimó que el volumen de datos de esta tabla estaba por debajo del nivel 10.000, por lo que no se estableció un índice.
Sin embargo, se encuentra que la cantidad de datos en esta tabla ha alcanzado el nivel de un millón, y la razón es que se ha generado una gran cantidad de consumo de reintentos, lo que lleva a una consulta lenta de esta tabla.
Por lo tanto, los datos de la tabla deben limpiarse. De hecho, después de eliminar datos con el comando DELETE, descubrimos que la velocidad de consulta no aumentó significativamente e incluso puede disminuir. ¿Por qué?
Debido a que el comando DELETE solo marca la fila de datos como "eliminada", no libera inmediatamente el espacio de almacenamiento ocupado por la fila de datos en el disco, lo que generará una gran cantidad de fragmentos en el archivo de datos, lo que afectará la consulta. actuación. Por lo tanto, además de eliminar registros de tablas, también es necesario limpiar fragmentos de disco.
Antes de la fragmentación de la tabla, nos enfocamos en los siguientes cuatro indicadores.
- Indicador 1: El estado de la tabla:
SHOW TABLE STATUS LIKE 'courier_consume_fail_message'; - Indicador 2: El número real de filas en la tabla:
SELECT count(*) FROM courier_consume_fail_message; - Indicador tres: el número de líneas a limpiar:
SELECT count(*) FROM courier_consume_fail_message where created_at < '2023-04-19 00:00:00'; - Indicador 4: Plan de ejecución de consulta de tabla:
EXPLAIN SELECT * FROM courier_consume_fail_message WHERE service='courier-transfer-mq';
-- 清理磁盘碎片
OPTIMIZE TABLE courier_consume_fail_message;
La siguiente es una comparación de indicadores antes y después de la limpieza.
1. Antes de limpiar
Indicador uno, el estado de la tabla:
Indicador 2, el número real de filas en la tabla: 76986
Indicador 3, el número de filas a limpiar: 76813
Indicador cuatro, el plan de ejecución de la consulta de tabla:
2. Limpiar los datos
Las siguientes son DELETE FROM courier_consume_fail_message WHERE created_at < '2023-04-19 00:00:00';las estadísticas después de la ejecución.
Indicador uno, el estado de la tabla:
Indicador 2, el número real de filas en la tabla: 173
Indicador tres, el número de filas a limpiar: 0
Indicador cuatro, el plan de ejecución de la consulta de tabla:
Del indicador 4, podemos ver que después de borrar los registros de la tabla, el número de filas escaneadas por la consulta permanece sin cambios: 8651048.
3. Limpia los escombros
Las siguientes son OPTIMIZE TABLE courier_consume_fail_message;las estadísticas después de la ejecución.
Indicador uno, el estado de la tabla:
Indicador cuatro, el plan de ejecución de la consulta de tabla:
Del indicador 4, podemos ver que después de limpiar los registros de la tabla, el número de filas escaneadas por la consulta se convierte en 100.
resumen
Se puede ver que la cantidad de filas de datos y la longitud de datos de la tabla se han limpiado, y también se ha reducido la cantidad de filas escaneadas por la declaración de consulta.
Para mejorar SELECT * FROM courier_consume_fail_message WHERE service='courier-transfer-mq';la eficiencia de consulta de la declaración, aún se debe establecer un índice.
alter` `table` `ec_courier.courier_consume_fail_message ``add` `index` `idx_service(service);
la cubierta
Artículos relacionados
Quizás también te interese el siguiente artículo.