MySQL-indexanvändningsfrågeoptimering

Några saker... Jag skulle ha ett ENKEL sammansatt index på( a_id, job, state, start_time )

Detta för att hjälpa till att optimera frågan på alla kriterier, i vad jag tror är den bäst inställda sekvensen. Ett enda "A_ID", sedan två jobb, ett litet tillståndsintervall, sedan tidsbaserat. Lägg sedan märke till inga citattecken... Det verkar som om du konverterade numeriska till strängjämförelser, lämna dem som numeriska för jämförelse -- snabbare än strängar.

Dessutom, genom att ha dem alla som en del av indexet, är det ett TÄCKANDE index, vilket betyder att det INTE behöver gå till råsidans data för att få de andra värdena att testa att de kvalificerande posterna ska inkluderas eller inte.

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;

Nu, varför indexet... överväg följande scenario. Du har två rum som har lådor... I det första rummet är varje ruta ett "a_id", inom det finns jobben i ordning, inom varje jobb är tillståndsintervallen och slutligen efter starttid.

I ett annat rum sorteras dina lådor efter starttid, inom det sorteras a_id och slutligen status.

Vilket skulle vara lättare att hitta det du behöver. Det är så man ska tänka på indexen. Jag skulle hellre gå till en ruta för "A_ID =614", sedan hoppa till jobb 1 och en annan för jobb 3. Inom varje jobb 1, jobb 3, ta 80-100, sedan tid. Du känner dock bättre till din data och volym i varje kriterium och kan justera.

Slutligen, count(ID) vs count(*). Allt jag bryr mig om är ett rekordkvalificerat. Jag behöver inte känna till det faktiska ID:t eftersom filtreringskriterierna redan är kvalificerade för att inkludera eller inte, varför leta (i det här fallet) efter det faktiska "ID".