No sé la diferencia que está viendo en sus instalaciones anteriores y actuales, pero el comportamiento de los servidores tiene sentido.
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;
En esta consulta, no tiene una cláusula where, pero solo obtiene una fila. Y eso es después de ordenar por create_time que pasa a tener un índice. Y ese índice se puede usar para clasificar. Pero veamos la segunda consulta.
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
No tiene un índice en la columna base. Entonces, no se puede usar ningún índice en eso. Para encontrar los registros relevantes, mysql tiene que hacer un escaneo de la tabla. Una vez identificadas las filas relevantes, es necesario ordenarlas. Pero en este caso, el planificador de consultas ha decidido que simplemente no vale la pena usar el índice en create_time
Veo varios problemas con su configuración, el primero es no tener un índice en base Como ya fue mencionado. Pero, ¿por qué es base varchar? Parece que estás almacenando números enteros en él.
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);
Y hacer múltiples índices como este no tiene mucho sentido en mysql. Eso es porque mysql puede usar solo un índice por tabla para consultas. Estaría mucho mejor con uno o dos índices. Posiblemente índices de varias columnas.
Creo que su índice ideal contendría los campos create_time y event
