Ясно е, че проблемът е, че заявката извършва сканиране на индекс. Алтернативният подход би бил да се направят две търсения на индекси, за първата и последната стойност, които са еднакви, и след това да се използва мета информация в индекса за изчислението. Въз основа на вашите наблюдения MySQL прави и двете.
Останалата част от този отговор е спекулация.
Причината, поради която производителността е „само“ 300 пъти по-бавна, а не 200 000 пъти по-бавна, се дължи на претоварването при четене на индекса. Всъщност сканирането на записите е доста бързо в сравнение с други операции, които са необходими.
Има фундаментална разлика между числата и низовете, когато става въпрос за сравнения. Машината може просто да разгледа битовите представяния на две числа и да разпознае дали са еднакви или различни. За съжаление, за низовете трябва да вземете под внимание кодирането/колирането. Мисля, че затова трябва да се гледат стойностите.
Възможно е, ако сте имали 216 000 копия на точно същия низ, тогава MySQL ще може да направи преброяването, използвайки метаданни в индекса. С други думи, индексаторът е достатъчно умен, за да използва метаданни за точни сравнения на равенство. Но не е достатъчно интелигентен, за да вземе предвид кодирането.
