Това се дължи на това, което наричам правилото за 5% на базата на ключова съвкупност (мощност на кортежа).
Ако индексирате таблица, където съществува едностранна мощност, MySQL Query Optimizer винаги ще избира пътя на най-малкото съпротивление.
ПРИМЕР:Ако таблица има колона за пол, кардиналитетът е две, M и F.
Какво ти индексира такава пол колона??? По същество получавате два гигантски свързани списъка.
Ако заредите един милион реда в таблица с колона за пол, може да получите 50% M и 50% F.
Индексът се прави безполезен по време на оптимизацията на заявки, ако мощността на комбинация от ключове (популация от ключове, както я изразих) е повече от 5% от общия брой на таблицата.
Сега по отношение на твоя пример защо двата различни плана EXPLAIN ??? Предполагам, че MySQL Query Optimizer и InnoDB като екип за етикети.
В първата CREATE TABLE таблицата и индексите са с приблизително еднакъв размер, макар и малки, така че той реши в полза на индекса, като направи сканиране на индекс, а не пълно сканиране на таблица . Имайте предвид, че неуникалните индекси носят вътрешния първичен ключ (RowID) на всеки ред в своите индексни записи, като по този начин правят индексите почти със същия размер като самата таблица.
Във втората CREATE TABLE, поради въвеждането на друга колона, потребител, сега карате оптимизатора на заявки да вижда напълно различен сценарий:таблицата вече е по-голяма от индексите . Следователно, оптимизаторът на заявки стана по-стриктен в тълкуването си как да се използват наличните индекси. Стигна се до правилото за 5%, което споменах преди. Това правило се провали мизерно и оптимизаторът на заявки реши в полза на пълно сканиране на таблицата.
