W InnoDB każdy indeks zawiera niejawnie klucz główny.
Plan wyjaśniania pokazuje, że indeks IDX_NOME jest używany w tabeli Paziente . DBMS wyszukuje nazwę w indeksie i znajduje ID_PAZIENTE tam, co jest kluczem, którego potrzebujemy, aby uzyskać dostęp do drugiej tabeli. Więc nie ma nic do dodania. (W innym DBMS dodalibyśmy indeks złożony na (NOME, ID_PAZIENTE) aby tak się stało.)
Następnie jest tabela Analisi do rozważenia. Znajdujemy rekord przez FK_ANALISI_PAZIENTE który zawiera ID_PAZIENTE który jest używany do znalezienia dopasowania i niejawnie klucza głównego ID_ANALISI które można wykorzystać do uzyskania dostępu do tabeli, ale nie jest to nawet konieczne, ponieważ wszystkie potrzebne nam informacje znajdują się w indeksie. W tabeli nie ma już nic, co musimy znaleźć. (Ponownie, w innym DBMS dodalibyśmy indeks złożony na (ID_PAZIENTE, ID_ANALISI) mieć indeks pokrycia.)
Więc to, co się dzieje, to po prostu:przeczytaj jeden indeks, aby przeczytać drugi, aby policzyć. Idealny. Nie ma nic do dodania.
moglibyśmy zastąp COUNT(analisi0_.ID_ANALISI) z COUNT(*) ponieważ pierwszy mówi tylko "licz rekordy, gdzie ID_ANALISI is not null", co zawsze ma miejsce jako ID_ANALISI jest kluczem podstawowym tabeli. Więc prościej jest użyć tego ostatniego i powiedzieć „policz rekordy”. Jednak nie spodziewam się, że spowoduje to znaczne przyspieszenie zapytania, jeśli w ogóle.
Tak więc z punktu widzenia zapytań nie ma nic, co mogłoby to przyspieszyć. Oto kolejne rzeczy, które przychodzą mi do głowy:
- Tabele partycjonowane? Nie, nie widziałbym w tym żadnej korzyści. Mogłoby być szybciej, gdyby zapytanie było wtedy wykonywane w równoległych wątkach, ale o ile wiem, nie ma równoległego wykonywania na wielu partycjach w MySQL. (Chociaż mogę się mylić.)
- Defragmentować tabele? Nie, same tabele nie są nawet dostępne w zapytaniu.
- Zostaje nam to:Kup lepszy sprzęt. (Przepraszam, że nie mam dla ciebie lepszej rady.)
