Hvorfor Index bruges kun, når det er tvunget, men ikke som standard?

for bedre ydeevne kan du prøve at bruge sammensat indeks .. baseret på kolonnen involveret i din where-klausul
og prøve at ændre IN-klausulen i en indre join
forudsat at dit IN-klausulindhold er et sæt faste værdier du kan bruge union (eller en ny tabel med den værdi, du har brug for)

fx ved at bruge union (du kan gøre noget lignende, hvis IN-sætningen er en underforespørgsel)

select user_table.colA ,ColB , count(*) as count 
from user_table 
INNER JOIN  ( 
  select 'FIXED1' colA
  union
  select 'FIXED2'
  ....
  union 
  select 'FIXEDX'
  )  t on t.colA = user_table.colA  
where colC >='2019-09-01 00:00:00' 
      and ColB = 17  
group by colA ,ColB;

du kan også tilføje et sammensat indeks på tabellen user_table på kolonner

   colA, colB, colC

for hvad der er relateret til element brugt af mysql query optimizer til at beslutte indekset til at bruge der flere aspekter og for alle disse tildeler query optimizer en omkostning
alt hvad du skal tage i betragtning

• kolonnen involveret i Where-klausulen
• Størrelsen af ​​tabellerne (og ikke yiuy tilfælde størrelsen af ​​tabellerne i join)
• Et skøn over, hvor mange rækker der vil blive hentet (for at beslutte, om der skal bruges et indeks eller blot scanne tabellen)
• hvis datatyperne matcher eller ej mellem kolonner i jion- og where-sætningen
• Brugen af ​​funktions- eller datatypekonvertering inklusiv fejl ved sortering
• Størrelsen af ​​indekset
• kardinalitet af indekset

og for alle disse mulighed vurderes en omkostning, og dette fører til, at indekset vælger

I dit tilfælde indebærer colC som dato en datakonvertering (respekter de bogstavelige værdier som streng ), og for dette er indekset ikke valgt ..

Er også for dette, at jeg har foreslået et sammensat indeks med kolonnen længst til venstre relateret til ikke-konverterede værdier