Algumas coisas... eu teria um ÚNICO índice composto em (a_id, job, state, start_time )
Isso para ajudar a otimizar a consulta em todos os critérios, no que acredito ser a sequência mais afinada. Um único "A_ID", depois dois trabalhos, um pequeno intervalo de estado e, em seguida, baseado em tempo. Em seguida, observe sem aspas... Parece que você estava convertendo comparações numéricas para strings, deixe-as como numéricas para comparar -- mais rápido que strings.
Além disso, por tê-los todos como parte do índice, é um índice COVERING, o que significa que NÃO precisa ir para os dados brutos da página para obter os outros valores para testar os registros de qualificação a serem incluídos ou não.
SELECT
count(*) AS tries
FROM
tasks
WHERE
a_id = 614
AND job IN ( 1, 3 )
AND state > 80 AND state < 100
AND start_time >= 1386538013;
Agora, o porquê do índice... considere o seguinte cenário. Você tem duas salas que têm caixas... Na primeira sala, cada caixa é um "a_id", dentro dela estão os trabalhos em ordem, dentro de cada trabalho estão os intervalos de estado e, finalmente, por hora de início.
Em outra sala, suas caixas são classificadas por hora de início, dentro desse a_id são classificadas e, finalmente, estado.
O que seria mais fácil de encontrar o que você precisa. É assim que você deve pensar sobre os índices. Eu preferiria ir para uma caixa para "A_ID =614", então pular para o Job 1 e outro para o Job 3. Dentro de cada Job 1, Job 3, pegue 80-100, então time. No entanto, você conhece melhor seus dados e volume em cada consideração de critério e pode ajustar.
Finalmente, o count(ID) vs count(*). Tudo o que me importa é um registro qualificado. Não preciso saber o ID real, pois os critérios de filtragem já qualificados como include ou não, por que procurar (neste caso) o "ID" real.
