Индексите не подобряват непременно производителността. За да разберете по-добре какво се случва, ще помогне, ако включите explain за различните заявки.
Най-доброто ми предположение би било, че имате индекс в id_state или дори id_state, id_mp които могат да се използват за удовлетворяване на where клауза. Ако е така, първата заявка без order by ще използва този индекс. Трябва да е доста бързо. Дори и без индекс, това изисква последователно сканиране на страниците в orders таблица, която все още може да бъде доста бърза.
След това, когато добавите индекса на creation_date , MySQL решава да използва този индекс вместо това за order by . Това изисква четене на всеки ред в индекса, след което извличане на съответната страница с данни, за да се провери where условия и връща колоните (ако има съвпадение). Това четене е изключително неефективно, защото не е в реда на "страниците", а по-скоро както е посочено от индекса. Произволните четения могат да бъдат доста неефективни.
Още по-лошо, въпреки че имате limit , все пак трябва да прочетете цялото таблица, защото е необходим целият набор от резултати. Въпреки че сте запазили сортиране на 38 записа, вие сте създали изключително неефективна заявка.
Между другото, тази ситуация се влошава значително, ако orders таблицата не се побира в наличната памет. След това имате състояние, наречено "разбиване", при което всеки нов запис има тенденция да генерира ново I/O четене. Така че, ако една страница има 100 записа върху нея, може да се наложи страницата да бъде прочетена 100 пъти.
Можете да накарате всички тези заявки да се изпълняват по-бързо, като имате индекс на orders(id_state, id_mp, creation_date) . where клаузата ще използва първите две колони и order by ще използва последното.
