В InnoDB всеки индекс съдържа неявно първичния ключ.
Планът за обяснение показва, че индексът IDX_NOME се използва в таблица Paziente . СУБД търси името в индекса и намира ID_PAZIENTE там, което е ключът, от който се нуждаем за достъп до другата таблица. Така че няма какво да добавя. (В друга СУБД бихме добавили съставен индекс към (NOME, ID_PAZIENTE) за да се случи това.)
След това има таблица Analisi да обмисли. Намираме запис чрез FK_ANALISI_PAZIENTE който съдържа ID_PAZIENTE който се използва за намиране на съвпадението и имплицитно първичния ключ ID_ANALISI който може да се използва за достъп до таблицата, но това дори не е необходимо, тъй като имаме цялата необходима информация от индекса. Не остана нищо, което трябва да намерим в таблицата. (Отново в друга СУБД бихме добавили съставен индекс към (ID_PAZIENTE, ID_ANALISI) да има покриващ индекс.)
Така че това, което се случва, е просто:прочетете един индекс, за да прочетете другия индекс, за да преброите. Перфектно. Няма какво да добавя.
Ние можем замени COUNT(analisi0_.ID_ANALISI) с COUNT(*) тъй като първият казва само "брой записи, където ID_ANALISI не е нула", което винаги е така като ID_ANALISI е първичният ключ на таблицата. Така че е по-лесно да използвате последното и да кажете „брой записи“. Въпреки това не очаквам това да ускори значително заявката, ако изобщо.
Така че от гледна точка на заявката няма какво да ускори това. Ето още неща, които идват на ум:
- Разделени таблици? Не, не бих видял полза от това. Тогава можеше да е по-бързо, ако заявката се изпълняваше в паралелни нишки, но доколкото знам, няма паралелно изпълнение на множество дялове в MySQL. (може и да греша.)
- Дефрагментиране на таблиците? Не, самите таблици дори не са достъпни в заявката.
- Това ни оставя с:Купете по-добър хардуер. (Съжалявам, че нямам по-добър съвет за вас.)
