Dette skyldes, hvad jeg kalder 5%-reglen baseret på nøglepopulation (tupelkardinalitet).
Hvis du indekserer en tabel, hvor der findes skæv kardinalitet, vil MySQL Query Optimizer altid vælge stien med mindst modstand.
EKSEMPEL :Hvis en tabel har en kønskolonne, er kardinalitet to, M og F.
Hvad er du indeksere sådan en køns kolonne ??? Du får i det væsentlige to gigantiske sammenkædede lister.
Hvis du indlæser en million rækker i en tabel med en kønskolonne, får du muligvis 50 % M og 50 % F.
Et indeks bliver ubrugeligt under forespørgselsoptimering, hvis kardinaliteten af en nøglekombination (nøglepopulation, som jeg formulerede det) er mere end 5 % af det samlede tabelantal.
Med hensyn til dit eksempel, hvorfor de to forskellige FORKLAR-planer ??? Mit gæt er MySQL Query Optimizer og InnoDB som et tag-team.
I den første CREATE TABLE er tabellen og indekserne omtrent lige store, selvom de er små, så det besluttede sig for indekset ved at lave en indeksscanning og ikke en fuld tabelscanning . Husk, at ikke-unikke indekser bærer rundt på hver rækkes interne primære nøgle (RowID) i dens indeksposter, hvilket gør indeksene næsten samme størrelse som selve tabellen.
I den anden OPRET TABEL på grund af introduktionen af en anden kolonne, bruger, får du nu Query Optimizer til at se et helt andet scenario:Tabellen er nu større end indekserne . Derfor blev Query Optimizer mere streng i sin fortolkning af, hvordan man bruger tilgængelige indekser. Det gik til 5%-reglen, jeg nævnte før. Den regel mislykkedes dybt, og Query Optimizer besluttede sig for en fuld tabelscanning.