Разликата в производителността е възможно поради e.id_dernier_fichier е в индекса, използван за JOIN, но e.codega да не съм втова индекс.
Без пълна дефиниция на двете таблици и всичките им индекси не е възможно да се каже със сигурност. Освен това включването на двата EXPLAIN PLAN за двете заявки би помогнало.
Засега обаче мога да разясня няколко неща...
Ако ИНДЕКСЪТ е ГРУПИРАН (това се отнася и за ПЪРВИЧНИТЕ КЛЮЧОВЕ), данните действително се съхраняват физически в реда на ИНДЕКСА. Това означава, че знаете, че искате позиция x в ИНДЕКС също подразбиране означава, че искате позиция x в ТАБЛИЦАТА.
Ако обаче INDEX не е групиран, INDEX просто ви предоставя справка. Ефективно казване на позиция x в ИНДЕКС съответства на позиция y в ТАБЛИЦАТА.
Важното тук е при достъп до полета, които не са посочени в ИНДЕКС. Това означава, че всъщност трябва да отидете до ТАБЛИЦАТА, за да получите данните. В случай на КЛУСТЕРИРАН ИНДЕКС, вие вече сте там, режийните разходи за намиране на това поле са доста ниски. Ако обаче ИНДЕКСЪТ не е групиран, вие на практика трябва да СЪЕДИНИТЕ ТАБЛИЦАТА към ИНДЕКСА, след което да намерите полето, което ви интересува.
Забележка; Наличие на съставен индекс на (id_dernier_fichier, codega) е много различно от наличието на един индекс само върху (id_dernier_fichier) и отделен индекс само за (codega) .
В случая на вашето запитване, не мисля, че изобщо трябва да променяте кода. Но вие можете се възползват от промяната на индексите.
Споменавате, че искате достъп до много полета. Поставянето на всички тези полета в съставен индекс вероятно не е най-доброто решение. Вместо това може да искате да създадете КЛУСТЕРИРАН ИНДЕКС на (id_dernier_fichier) . Това ще означава, че след като *id_dernier_fichier* бъде локализиран, вече сте на правилното място, за да получите и всички останали полета.
РЕДАКТИРАНЕ Забележка относно MySQL и КЛУСТЕРИРАНИ ИНДЕКСИ
13.2.10.1. Клъстерирани и вторични индекси
Всяка InnoDB таблица има специален индекс, наречен клъстерен индекс, където се съхраняват данните за редовете:
- Ако дефинирате ПЪРВИЧЕН КЛЮЧ на вашата таблица, InnoDB го използва като клъстерен индекс.
- Ако не дефинирате ПЪРВИЧЕН КЛЮЧ за вашата таблица, MySQL избира първия УНИКАЛЕН индекс, който има само НЕ НУЛЕВИ колони като първичен ключ и InnoDB го използва като клъстерен индекс.
- Ако таблицата няма ПЪРВИЧЕН КЛЮЧ или подходящ УНИКАЛЕН индекс, InnoDB вътрешно генерира скрит клъстерен индекс на синтетична колона, съдържаща стойности на ID на ред. Редовете са подредени по ID, който InnoDB присвоява на редовете в такава таблица. Идентификаторът на реда е 6-байтово поле, което се увеличава монотонно с вмъкването на нови редове. По този начин редовете, подредени по ID на реда, са физически в ред на вмъкване.
