Mientras se acerca a 'respetable ', 2 Millones de filas sigue siendo un tamaño relativamente pequeño para una tabla. (Y por lo tanto, normalmente es posible un rendimiento más rápido)
Como descubrió, los comodines frontales son particularmente ineficientes y tendremos que encontrar una solución para esto si ese caso de uso es común para su aplicación.
Podría ser que no tenga el conjunto correcto de índices . Sin embargo, antes de continuar, deseo recalcar que, si bien los índices generalmente mejoran el rendimiento de DBMS con declaraciones SELECT de todo tipo, sistemáticamente tienen un efecto negativo en el rendimiento de las operaciones "CUD" (es decir, con SQL CREATE/INSERT, UPDATE , verbos DELETE, es decir, las consultas que escriben a la base de datos en lugar de simplemente leer lo). En algunos casos, el impacto negativo de los índices en las consultas de "escritura" puede ser muy significativo.
Mi razón para enfatizar particularmente la naturaleza ambivalente de los índices es que parece que su aplicación realiza una buena cantidad de recopilación de datos como parte normal de su funcionamiento, y deberá estar atento a una posible degradación a medida que las consultas INSERT se ralentizan. . Una posible alternativa es realizar la recopilación de datos en una tabla/base de datos relativamente pequeña, sin índices o con muy pocos, e importar regularmente los datos de esta base de datos de entrada a una base de datos donde se lleva a cabo la extracción de datos real. (Después de importarlas, las filas se pueden eliminar de la "base de datos de entrada", manteniéndola pequeña y rápida para su función INSERTAR).
Otra inquietud/pregunta es sobre el ancho de una fila en la tabla de conversión (el número de columnas y la suma de los anchos de estas columnas). El mal rendimiento podría estar relacionado con el hecho de que las filas son demasiado anchas, lo que da como resultado muy pocas filas en los nodos hoja de la tabla y, por lo tanto, una estructura de árbol más profunda de lo necesario.
Volviendo a los índices...
en vista de las pocas consultas en la pregunta, parece que podría beneficiarse de un índice ip + note (un índice hecho al menos con estas dos claves en este orden). Aquí no se puede hacer un análisis completo de la situación del índice y, francamente, una posible revisión del esquema de la base de datos (no hay suficiente información para uno...) pero el proceso general para hacerlo es hacer una lista de los casos de uso más comunes y para ver qué índices de bases de datos podrían ayudar con estos casos. Uno puede obtener información sobre cómo se manejan las consultas particulares, inicialmente o después de agregar los índices, con el comando EXPLAIN de mySQL.
La normalización O la desmormalización (¡o incluso una combinación de ambas!) suele ser también una idea viable para mejorar el rendimiento durante las operaciones mineras.
