I InnoDB innehåller varje index primärnyckeln implicit.
Förklaringsplanen visar det indexet IDX_NOME används i tabellen Paziente . DBMS letar upp namnet i indexet och hittar ID_PAZIENTE där inne, vilket är nyckeln vi behöver för att komma åt den andra tabellen. Så det finns inget att tillägga. (I en annan DBMS skulle vi ha lagt till ett sammansatt index på (NOME, ID_PAZIENTE) för att detta ska hända.)
Sedan finns det tabellen Analisi att överväga. Vi hittar en post via FK_ANALISI_PAZIENTE som innehåller ID_PAZIENTE som används för att hitta matchningen, och implicit primärnyckeln ID_ANALISI som skulle kunna användas för att komma åt tabellen, men detta är inte ens nödvändigt, eftersom vi har all information vi behöver från indexet. Det finns inget kvar som vi behöver hitta i tabellen. (Återigen, i en annan DBMS skulle vi ha lagt till ett sammansatt index på (ID_PAZIENTE, ID_ANALISI) att ha ett täckande index.)
Så vad som händer är bara:läs ett index för att läsa det andra indexet för att räkna. Perfekt. Det finns inget att tillägga.
Vi kunde ersätt COUNT(analisi0_.ID_ANALISI) med COUNT(*) eftersom den förra bara säger "räkna poster där ID_ANALISI är inte null", vilket alltid är fallet som ID_ANALISI är tabellens primärnyckel. Så det är enklare att använda det senare och säga "räkna poster". Jag förväntar mig dock inte att detta kommer att påskynda frågan nämnvärt om alls.
Så ur frågesynpunkt finns det inget som påskyndar detta. Här är ytterligare saker som kommer att tänka på:
- Partitionerade tabeller? Nej, jag skulle inte se någon fördel med detta. Det kunde vara snabbare om frågan kördes i parallella trådar då, men så vitt jag vet finns det ingen parallell exekvering på flera partitioner i MySQL. (Jag kan dock ha fel.)
- Defragmenterar du tabellerna? Nej, själva tabellerna nås inte ens i frågan.
- Det lämnar oss med:Köp bättre hårdvara. (Tyvärr att jag inte har några bättre råd till dig.)