MySQL-indeksforbrugsforespørgselsoptimering

Et par ting... Jeg ville have et ENKELT sammensat indeks på( a_id, job, state, start_time )

Dette for at hjælpe med at optimere forespørgslen på alle kriterierne, i hvad jeg mener er den bedst indstillede rækkefølge. Et enkelt "A_ID", derefter to job, et lille tilstandsområde og derefter tidsbaseret. Læg derefter mærke til ingen anførselstegn... Det ser ud til, at du konverterede numeriske til strengsammenligninger, lad dem være numeriske for at sammenligne -- hurtigere end strenge.

Også ved at have dem alle som en del af indekset, er det et DÆKENDE indeks, hvilket betyder, at det IKKE behøver at gå til de rå sidedata for at få de andre værdier til at teste de kvalificerende poster til at inkludere eller ej.

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, hvorfor indekset... overvej følgende scenarie. Du har to rum, der har kasser... I det første rum er hver boks en "a_id", inden for det er jobs i rækkefølge, inden for hvert job er tilstandsintervallerne, og endelig efter starttidspunkt.

I et andet rum er dine kasser sorteret efter starttidspunkt, inden for det er a_id sorteret, og til sidst tilstand.

Hvilket ville være nemmere at finde det, du har brug for. Sådan skal du tænke på indekserne. Jeg vil hellere gå til én boks for "A_ID =614", så hoppe til Job 1 og en anden for Job 3. Inden for hver Job 1, Job 3, snup 80-100, derefter tid. Du kender dog bedre dine data og volumen i de enkelte kriterier og kan justere.

Til sidst, count(ID) vs count(*). Det eneste, jeg bekymrer mig om, er en rekordkvalificeret. Jeg behøver ikke at kende det faktiske ID, da filtreringskriterierne allerede er kvalificeret til at inkludere eller ej, hvorfor kigge (i dette tilfælde) efter det faktiske "ID".