In InnoDB ogni indice contiene implicitamente la chiave primaria.
Il piano di spiegazione mostra quell'indice IDX_NOME è usato sulla tabella Paziente . Il DBMS cerca il nome nell'indice e trova ID_PAZIENTE lì dentro, che è la chiave di cui abbiamo bisogno per accedere all'altra tabella. Quindi non c'è niente da aggiungere. (In un altro DBMS avremmo aggiunto un indice composito su (NOME, ID_PAZIENTE) affinché ciò avvenga.)
Poi c'è la tabella Analisi considerare. Troviamo un record tramite FK_ANALISI_PAZIENTE che contiene il ID_PAZIENTE che viene utilizzata per trovare la corrispondenza, e implicitamente la chiave primaria ID_ANALISI che potrebbe essere utilizzato per accedere alla tabella, ma questo non è nemmeno necessario, perché abbiamo tutte le informazioni di cui abbiamo bisogno dall'indice. Non c'è più niente che dobbiamo trovare nella tabella. (Anche in un altro DBMS avremmo aggiunto un indice composito su (ID_PAZIENTE, ID_ANALISI) avere un indice di copertura.)
Quindi quello che succede è semplicemente:leggere un indice per leggere l'altro indice per contare. Perfetto. Non c'è niente da aggiungere.
Potremmo sostituire COUNT(analisi0_.ID_ANALISI) con COUNT(*) come dice solo il primo "conta i record in cui ID_ANALISI non è null", che è sempre il caso di ID_ANALISI è la chiave primaria della tabella. Quindi è più semplice usare quest'ultimo e dire "conta i record". Tuttavia, non mi aspetto che ciò acceleri notevolmente la query, se non del tutto.
Quindi dal punto di vista della query, non c'è nulla per accelerare questo. Ecco altre cose che mi vengono in mente:
- Tabelle partizionate? No, non vedrei alcun vantaggio in questo. Potrebbe essere più veloce se la query fosse eseguita in thread paralleli, ma per quanto ne so, non esiste un'esecuzione parallela su più partizioni in MySQL. (Potrei sbagliarmi però.)
- Deframmentazione delle tabelle? No, le tabelle stesse non sono nemmeno accessibili nella query.
- Questo ci lascia con:Acquista hardware migliore. (Mi dispiace non avere un consiglio migliore per te.)
