Neznám rozdíl, který vidíte ve svých předchozích a současných instalacích, ale chování serverů dává smysl.
SELECT test_events.create_time FROM test_events LEFT JOIN test_event_types ON ( test_events.event = test_event_types.id ) ORDER BY test_events.create_time DESC LIMIT 1;
V tomto dotazu nemáte klauzuli where, ale načítáte pouze jeden řádek. A to po seřazení podle create_time
který náhodou má index. A tento index lze použít k řazení. Ale podívejme se na druhý dotaz.
SELECT test_events.create_time FROM test_events LEFT JOIN test_event_types ON ( test_events.event = test_event_types.id ) WHERE base = 314 ORDER BY test_events.create_time DESC LIMIT 1
V základním sloupci nemáte index. Takže na to nelze použít žádný index. Chcete-li najít příslušné záznamy, mysql musí provést skenování tabulky. Po identifikaci příslušných řádků je třeba je seřadit. Ale v tomto případě se plánovač dotazů rozhodl, že se prostě nevyplatí používat index na create_time
Vidím několik problémů s vaším nastavením, přičemž prvním je nedostatek a indexování na base
jak již bylo zmíněno. Ale proč je základní varchar? Zdá se, že do něj ukládáte celá čísla.
ALTER TABLE test_events
ADD PRIMARY KEY (id),
ADD KEY client (client),
ADD KEY event_time (event_time),
ADD KEY manager (manager),
ADD KEY base_id (base_id),
ADD KEY create_time (create_time);
A dělat takto více indexů nedává v mysql moc smysl. Je to proto, že mysql může pro dotazy používat pouze jeden index na tabulku. Daleko lépe byste na tom byli s jedním nebo dvěma indexy. Možná vícesloupcové indexy.
Myslím, že váš ideální index by obsahoval jak pole create_time, tak pole událostí