Algunas cosas... Tendría un índice compuesto ÚNICO en (a_id, job, state, start_time)
Esto para ayudar a optimizar la consulta en todos los criterios, en lo que creo que es la secuencia mejor ajustada. Un solo "A_ID", luego dos trabajos, un rango de estado pequeño, luego basado en el tiempo. A continuación, observe que no hay comillas... Parece que estaba convirtiendo comparaciones numéricas en cadenas, déjelas como numéricas para comparar, más rápido que las cadenas.
Además, al tenerlos a todos como parte del índice, es un índice de CUBIERTA, lo que significa que NO tiene que ir a los datos de la página sin procesar para obtener los otros valores para probar los registros de calificación para incluirlos o no.
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;
Ahora, el por qué del índice... considere el siguiente escenario. Tienes dos salas que tienen cajas... En la primera sala, cada caja es un "a_id", dentro de eso están los trabajos en orden, dentro de cada trabajo están los rangos de estado y finalmente por hora de inicio.
En otra habitación, sus cajas se ordenan por hora de inicio, dentro de ese a_id se ordenan y finalmente se declaran.
Que sería más fácil encontrar lo que necesitas. Así es como se debe pensar en los índices. Preferiría ir a un cuadro para "A_ID =614", luego saltar al Trabajo 1 y otro para el Trabajo 3. Dentro de cada Trabajo 1, Trabajo 3, tome 80-100, luego tiempo. Sin embargo, conoce mejor sus datos y volumen en cada consideración de criterio y puede ajustar.
Finalmente, el conteo (ID) vs conteo (*). Todo lo que me importa es un récord calificado. No necesito saber el ID real ya que los criterios de filtrado ya están calificados como incluir o no, ¿por qué buscar (en este caso) el "ID" real?
