Quelques petites choses... J'aurais un SEUL index composé sur( a_id, job, state, start_time )
Ceci pour aider à optimiser la requête sur tous les critères, dans ce que je pense être la séquence la mieux réglée. Un seul "A_ID", puis deux travaux, une petite plage d'états, puis basés sur le temps. Ensuite, remarquez qu'il n'y a pas de guillemets... Il semble que vous convertissiez des comparaisons numériques en chaînes, laissez-les comme numériques pour la comparaison - plus rapide que les chaînes.
De plus, en les ayant tous dans le cadre de l'index, il s'agit d'un index COVERING, ce qui signifie qu'il n'est PAS nécessaire d'accéder aux données brutes de la page pour obtenir les autres valeurs afin de tester les enregistrements éligibles à inclure ou non.
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;
Maintenant, pourquoi l'index... considérez le scénario suivant. Vous avez deux salles qui ont des boîtes... Dans la première salle, chaque boîte est un "a_id", à l'intérieur duquel se trouvent les travaux dans l'ordre, dans chaque travail se trouvent les plages d'état, et enfin par heure de début.
Dans une autre pièce, vos boîtes sont triées par heure de début, à l'intérieur de laquelle a_id sont triées, et enfin par état.
Ce qui serait plus facile de trouver ce dont vous avez besoin. C'est ainsi que vous devriez penser sur les index. Je préférerais aller dans une case pour "A_ID =614", puis passer au travail 1 et à un autre pour le travail 3. Dans chaque travail 1, travail 3, saisissez 80-100, puis le temps. Vous connaissez cependant mieux vos données et votre volume dans chaque critère de considération et pouvez vous ajuster.
Enfin, le count(ID) vs count(*). Tout ce qui m'intéresse, c'est un record qualifié. Je n'ai pas besoin de connaître l'ID réel car les critères de filtrage sont déjà qualifiés d'inclus ou non, pourquoi rechercher (dans ce cas) l'"ID" réel.
