Tak to chodí. Vydržte se mnou chvilku...
Optimalizátor by chtěl použít INDEX, v tomto případě ACTI_DATE_I. Ale nechce to používat, pokud by to bylo pomalejší.
Plán A:Použijte index.
- Sáhněte do indexu strukturovaného BTree na konci (kvůli DESC)
- Skenovat dozadu
- Pro každý řádek v indexu vyhledejte odpovídající řádek v datech. Poznámka:Index má (ACTIVITY_DATE, ACTIVITY_ID), protože PRIMARY KEY je implicitně připojen k jakémukoli sekundárnímu klíči. Další vyhledávání v BTree, potenciálně náhodné, je dosáhnout „dat“ pomocí PK (ACTIVITY_ID). Proto je potenciálně pomalý. (Ve vašem případě ale ne příliš pomalu.)
- Toto skončí po LIMIT řádcích.
Plán B:Ignorujte tabulku
- Naskenujte tabulku a vytvořte tabulku tmp. (Pravděpodobně v paměti.)
- Seřaďte tabulku tmp
- Odloupněte LIMIT řádků.
Ve vašem případě (96 -- 1 % z 10 kB) je překvapivé, že si vybral skenování tabulky. Normálně je hranice někde kolem 10 % až 30 % počtu řádků v tabulce.
ANALYZE TABLE měl by způsobily přepočet statistik, což mohlo přesvědčili ho, aby šel s druhým plánem.
Jakou verzi MySQL používáte? (Ne, nevím o žádných změnách v této oblasti.)
Můžete zkusit jednu věc:OPTIMIZE TABLE ACTIVITIES; Tím se stůl znovu sestaví, čímž se bloky znovu zabalí a povede to k potenciálně různé statistiky. Pokud to pomůže, rád bych to věděl – protože normálně říkám „Optimalizovat tabulku je k ničemu“.