Oczywiście problem polega na tym, że zapytanie wykonuje skanowanie indeksu. Alternatywnym podejściem byłoby wykonanie dwóch wyszukiwań indeksu dla pierwszej i ostatniej wartości, które są takie same, a następnie użycie metainformacji w indeksie do obliczeń. Bazując na Twoich obserwacjach, MySQL robi obie te rzeczy.
Reszta tej odpowiedzi to spekulacje.
Powodem, dla którego wydajność jest „tylko” 300 razy wolniejsza, a nie 200 000 razy wolniejsza, jest narzut związany z odczytem indeksu. W rzeczywistości skanowanie wpisów jest dość szybkie w porównaniu do innych potrzebnych operacji.
Istnieje zasadnicza różnica między liczbami a ciągami, jeśli chodzi o porównania. Silnik może po prostu spojrzeć na bitowe reprezentacje dwóch liczb i rozpoznać, czy są one takie same, czy różne. Niestety w przypadku ciągów trzeba wziąć pod uwagę kodowanie/porównanie. Myślę, że właśnie dlatego musi przyjrzeć się wartościom.
Możliwe, że gdybyś miał 216 000 kopii dokładnie ten sam ciąg, wtedy MySQL będzie w stanie wykonać zliczanie za pomocą metadanych w indeksie. Innymi słowy, indeksator jest wystarczająco inteligentny, aby używać metadanych do dokładnych porównań równości. Ale nie jest wystarczająco sprytne, aby brać pod uwagę kodowanie.
