En InnoDB, cada índice contiene implícitamente la clave principal.
El plan de explicación muestra que el índice IDX_NOME se usa en la mesa Paziente . El DBMS busca el nombre en el índice y encuentra ID_PAZIENTE allí, que es la clave que necesitamos para acceder a la otra tabla. Así que no hay nada que agregar. (En otro DBMS habríamos agregado un índice compuesto en (NOME, ID_PAZIENTE) para que esto suceda.)
Luego está la tabla Analisi considerar. Encontramos un registro vía FK_ANALISI_PAZIENTE que contiene el ID_PAZIENTE que se utiliza para encontrar la coincidencia e implícitamente la clave principal ID_ANALISI que podría usarse para acceder a la tabla, pero esto ni siquiera es necesario, porque tenemos toda la información que necesitamos del índice. No queda nada que necesitemos encontrar en la tabla. (Nuevamente, en otro DBMS habríamos agregado un índice compuesto en (ID_PAZIENTE, ID_ANALISI) para tener un índice de cobertura.)
Entonces, lo que sucede es simplemente:leer un índice para leer el otro índice para contar. Perfecto. No hay nada que agregar.
Nosotros podríamos reemplazar COUNT(analisi0_.ID_ANALISI) con COUNT(*) como el primero solo dice "contar registros donde ID_ANALISI no es nulo", que siempre es el caso como ID_ANALISI es la clave principal de la tabla. Por lo tanto, es más sencillo usar este último y decir "contar registros". Sin embargo, no espero que esto acelere la consulta significativamente, si es que lo hace.
Entonces, desde el punto de vista de la consulta, no hay nada que acelere esto. Aquí hay más cosas que me vienen a la mente:
- ¿Tablas particionadas? No, no vería ningún beneficio en esto. Podría ser más rápido si la consulta se ejecutara en subprocesos paralelos, pero hasta donde yo sé, no hay una ejecución paralela en múltiples particiones en MySQL. (Aunque puede que me equivoque).
- ¿Desfragmentar las tablas? No, ni siquiera se accede a las tablas en la consulta.
- Eso nos deja con:Comprar mejor hardware. (Lamento no tener mejores consejos para ti).
