Няколко неща... щях да имам ЕДИН СЛОЖЕН индекс на (a_id, job, state, start_time)
Това, за да помогне за оптимизиране на заявката по всички критерии, в това, което смятам, че е най-добре настроената последователност. Един единствен "A_ID", след това две задачи, малък диапазон на състоянието, след това базиран на време. След това не забелязвайте кавички... Изглежда, че преобразувахте числови в сравнения на низове, оставете ги като числови за сравнение – по-бързо от низовете.
Освен това, като ги има всички като част от индекса, това е ПОКРИВАЩ индекс, което означава, че НЕ трябва да отива към необработените данни на страницата, за да получи другите стойности за тестване на квалифициращите записи за включване или не.
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;
Сега, защо индексът... разгледайте следния сценарий. Имате две стаи, които имат кутии... В първата стая всяка кутия е "a_id", вътре в нея са заданията по ред, във всяко задание са диапазоните на състоянието и накрая по начален час.
В друга стая вашите кутии се сортират по начален час, в рамките на това a_id се сортират и накрая се състоят.
Което би било по-лесно да намерите това, от което се нуждаете. Така трябва да мислите за индексите. Бих предпочел да отида в едно поле за "A_ID =614", след което да прескоча до работа 1 и друга за работа 3. Във всяка работа 1, работа 3 вземете 80-100, след това време. Вие обаче познавате по-добре своите данни и обем при разглеждане на всеки критерий и може да коригирате.
И накрая, count(ID) срещу count(*). Единственото нещо, което ме интересува, е рекордно квалифицирано. Не е нужно да знам действителния идентификатор, тъй като критериите за филтриране вече са квалифицирани като включват или не, защо да търсим (в този случай) действителния „ID“.
