V InnoDB každý index implicitně obsahuje primární klíč.
Plán vysvětlení ukazuje, že index IDX_NOME se používá na stole Paziente . DBMS vyhledá název v indexu a najde ID_PAZIENTE tam, což je klíč, který potřebujeme pro přístup k druhé tabulce. Takže není co dodat. (V jiném DBMS bychom přidali složený index na (NOME, ID_PAZIENTE) aby se tak stalo.)
Dále je zde tabulka Analisi zvážit. Najdeme záznam přes FK_ANALISI_PAZIENTE který obsahuje ID_PAZIENTE který se používá k nalezení shody a implicitně primární klíč ID_ANALISI který by mohl být použit pro přístup k tabulce, ale to ani není nutné, protože všechny informace, které potřebujeme, máme z indexu. V tabulce nezbývá nic, co bychom potřebovali najít. (Opět bychom v jiném DBMS přidali složený index na (ID_PAZIENTE, ID_ANALISI) mít krycí index.)
Takže to, co se stane, je pouze:číst jeden index, abyste mohli číst druhý index, abyste mohli počítat. Perfektní. Není co dodat.
Mohli nahradit COUNT(analisi0_.ID_ANALISI) s COUNT(*) jak první říká pouze "počítat záznamy, kde ID_ANALISI není null", což je vždy případ ID_ANALISI je primární klíč tabulky. Je tedy jednodušší použít to druhé a říct „spočítat záznamy“. Neočekávám však, že by to výrazně urychlilo dotaz, pokud vůbec.
Takže z pohledu dotazu není nic, co by to urychlilo. Zde jsou další věci, které mě napadají:
- Rozdělené tabulky? Ne, neviděl bych v tom žádný přínos. Mohlo by to být rychlejší, kdyby byl dotaz prováděn v paralelních vláknech, ale pokud vím, neexistuje žádné paralelní provádění na více oddílech v MySQL. (Mohu se však mýlit.)
- Defragmentovat tabulky? Ne, samotné tabulky nejsou v dotazu ani přístupné.
- Zbývá nám:Koupit lepší hardware. (Omlouvám se, že pro vás nemám lepší radu.)