É assim que as coisas acontecem. Tenha paciência comigo um minuto...
O Optimizer gostaria de usar um INDEX, neste caso ACTI_DATE_I. Mas ele não quer usá-lo se isso for mais lento.
Plano A:Use o índice.
- Acessar o índice estruturado BTree no final (por causa do DESC)
- Verificar para trás
- Para cada linha no índice, procure a linha correspondente nos dados. Nota:O índice tem (ACTIVITY_DATE, ACTIVITY_ID) porque a PRIMARY KEY é anexada implicitamente a qualquer chave secundária. Para acessar os "dados" usando o PK (ACTIVITY_ID) é outra pesquisa BTree, potencialmente aleatória. Portanto, é potencialmente lento. (Mas não muito lento no seu caso.)
- Isso para após LIMIT linhas.
Plano B:Ignore a mesa
- Digitalize a tabela, criando uma tabela tmp. (Provavelmente estará na memória.)
- Ordenar a tabela tmp
- Retire LIMIT linhas.
No seu caso (96 -- 1% de 10K) é surpreendente que ele tenha escolhido a varredura da tabela. Normalmente, o corte é algo em torno de 10% a 30% do número de linhas na tabela.
ANALYZE TABLE deveria causaram um recálculo das estatísticas, o que poderia convencê-lo a ir com o outro Plano. Qual versão do MySQL você está usando? (Não, não conheço nenhuma mudança nessa área.)
Uma coisa que você pode tentar:
OPTIMIZE TABLE ACTIVITIES; Isso reconstruirá a tabela, reempacotando os blocos e levando a potencialmente estatísticas diferentes. Se isso ajudar, gostaria de saber - já que normalmente digo "Otimizar tabela é inútil". 
