Detta beror på vad jag kallar 5%-regeln baserad på nyckelpopulation (tupelkardinalitet).
Om du indexerar en tabell med skev kardinalitet, kommer MySQL Query Optimizer alltid att välja vägen för minsta motstånd.
EXEMPEL :Om en tabell har en könskolumn är kardinalitet två, M och F.
Vad är det du indexerar en sådan könskolumn ??? Du får i princip två gigantiska länkade listor.
Om du laddar en miljon rader i en tabell med en könskolumn kan du få 50 % M och 50 % F.
Ett index görs oanvändbart under frågeoptimering om kardinaliteten för en nyckelkombination (nyckelpopulation som jag formulerade det) är mer än 5 % av det totala antalet tabeller.
Nu, med hänsyn till ditt exempel, varför de två olika EXPLAIN-planerna ??? Min gissning är MySQL Query Optimizer och InnoDB som ett taggteam.
I den första CREATE TABLE är tabellen och indexen ungefär lika stora även om de är små, så det bestämde sig för indexet genom att göra en indexskanning inte en fullständig tabellskanning . Tänk på att icke-unika index bär runt varje rads interna primärnyckel (RowID) i dess indexposter, vilket gör att indexen blir nästan lika stora som själva tabellen.
I den andra SKAPA TABELL, på grund av introduktionen av en annan kolumn, användare, låter du nu frågeoptimeraren se ett helt annat scenario:Tabellen är nu större än indexen . Därför blev Query Optimizer mer strikt i sin tolkning av hur man använder tillgängliga index. Det gick till 5%-regeln jag nämnde tidigare. Den regeln misslyckades totalt och frågeoptimeraren bestämde sig för en genomsökning av hela tabellen.