Така вървят нещата. Изчакайте малко...
Оптимизаторът би искал да използва ИНДЕКС, в този случай ACTI_DATE_I. Но не иска да го използва, ако това би било по-бавно.
План А:Използвайте индекса.
- Достигнете до структурирания индекс BTree в края (заради DESC)
- Сканиране назад
- За всеки ред в индекса потърсете съответния ред в данните. Забележка:Индексът има (ACTIVITY_DATE, ACTIVITY_ID), защото ПЪРВИЧНИЯТ КЛЮЧ е имплицитно добавен към всеки вторичен ключ. За да достигнете до „данните“ с помощта на PK (ACTIVITY_ID) е друго търсене на BTree, потенциално произволно. Следователно е потенциално бавно. (Но не много бавно във вашия случай.)
- Това спира след LIMIT реда.
План Б:Игнорирайте таблицата
- Сканирайте таблицата, създавайки tmp таблица. (Вероятно е в паметта.)
- Сортирайте таблицата tmp
- Отлепете LIMIT реда.
Във вашия случай (96 -- 1% от 10K) е изненадващо, че избра сканирането на таблицата. Обикновено границата е някъде около 10% -30% от броя на редовете в таблицата.
ANALYZE TABLE трябва са довели до преизчисляване на статистиката, което може са го убедили да върви с другия план.
Каква версия на MySQL използвате? (Не, не знам за промени в тази област.)
Едно нещо, което бихте могли да опитате:OPTIMIZE TABLE ACTIVITIES; Това ще възстанови таблицата, като по този начин ще преопакова блоковете и ще доведе до потенциално различни статистики. Ако това помогне, бих искал да го знам – тъй като обикновено казвам „Оптимизиране на таблицата е безполезно“.
