Kilka rzeczy... Miałbym POJEDYNCZY indeks złożony na (a_id, job, state, start_time )
Ma to pomóc zoptymalizować zapytanie według wszystkich kryteriów, w tym, co uważam za najlepiej dostrojoną sekwencję. Pojedyncze "A_ID", potem dwa zadania, mały zakres stanów, potem czas. Następnie zauważ, że nie ma cudzysłowów... Wygląda na to, że konwertowałeś porównania liczbowe na ciągi znaków, zostaw je jako liczbowe do porównania - szybciej niż ciągi.
Ponadto dzięki temu, że wszystkie są częścią indeksu, jest to indeks COVERING, co oznacza, że NIE musi przechodzić do nieprzetworzonych danych strony, aby uzyskać inne wartości w celu przetestowania kwalifikujących się rekordów do uwzględnienia lub nie.
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;
Teraz, dlaczego indeks... Rozważmy następujący scenariusz. Masz dwa pokoje, które mają pudełka... W pierwszym pokoju każde pudełko jest „a_id”, w ramach którego znajdują się zadania w kolejności, w każdym zadaniu są zakresy stanów, a na końcu według czasu rozpoczęcia.
W innym pokoju twoje pudełka są sortowane według czasu rozpoczęcia, w tym a_id są sortowane, a na końcu według stanu.
Który byłby łatwiejszy do znalezienia tego, czego potrzebujesz. Tak powinieneś myśleć o indeksach. Wolałbym przejść do jednego pola dla „A_ID =614”, a następnie przejść do Zadania 1 i drugiego dla Zadania 3. W ramach każdego Zadania 1, Zadania 3, weź 80-100, a następnie czas. Jednak znasz lepiej swoje dane i objętość w każdym kryterium i możesz się dostosować.
Na koniec count(ID) vs count(*). Jedyne, na czym mi zależy, to rekordowa kwalifikacja. Nie muszę znać rzeczywistego identyfikatora, ponieważ kryteria filtrowania zostały już zakwalifikowane jako uwzględnianie lub nie, po co szukać (w tym przypadku) rzeczywistego „identyfikatora”.
