I InnoDB indeholder hvert indeks den primære nøgle implicit.
Forklaringsplanen viser det indeks IDX_NOME bruges på tabellen Paziente . DBMS'en slår navnet op i indekset og finder ID_PAZIENTE derinde, hvilket er den nøgle, vi skal bruge for at få adgang til den anden tabel. Så der er ikke noget at tilføje. (I et andet DBMS ville vi have tilføjet et sammensat indeks på (NOME, ID_PAZIENTE) for at dette kan ske.)
Så er der tabellen Analisi at overveje. Vi finder en post via FK_ANALISI_PAZIENTE som indeholder ID_PAZIENTE som bruges til at finde matchet, og implicit den primære nøgle ID_ANALISI som kunne bruges til at få adgang til tabellen, men det er ikke engang nødvendigt, fordi vi har alle de oplysninger, vi har brug for, fra indekset. Der er intet tilbage, som vi skal finde i tabellen. (Igen, i en anden DBMS ville vi have tilføjet et sammensat indeks på (ID_PAZIENTE, ID_ANALISI) at have et dækkende indeks.)
Så hvad der sker er blot:læs det ene indeks for at læse det andet indeks for at tælle. Perfekt. Der er ikke noget at tilføje.
Vi kunne erstatte COUNT(analisi0_.ID_ANALISI) med COUNT(*) da førstnævnte kun siger "tæller poster hvor ID_ANALISI er ikke null", hvilket altid er tilfældet som ID_ANALISI er tabellens primære nøgle. Så det er nemmere at bruge sidstnævnte og sige "tæl poster". Jeg forventer dog ikke, at dette vil fremskynde forespørgslen væsentligt, hvis overhovedet.
Så fra et spørgsmålssynspunkt er der intet til at fremskynde dette. Her er flere ting, der kommer til at tænke på:
- Opdelte tabeller? Nej, det ville jeg ikke se nogen fordel i. Det kunne være hurtigere, hvis forespørgslen blev udført i parallelle tråde, men så vidt jeg ved, er der ingen parallel eksekvering på flere partitioner i MySQL. (Jeg kan dog tage fejl.)
- Vil du defragmentere tabellerne? Nej, selve tabellerne er ikke engang tilgået i forespørgslen.
- Det efterlader os med:Køb bedre hardware. (Beklager ikke at have et bedre råd til dig.)