Problemet er klart, at forespørgslen laver en indeksscanning. Den alternative tilgang ville være at lave to indeksopslag, for den første og sidste værdi, der er ens, og derefter bruge metainformation i indekset til beregningen. Baseret på dine observationer gør MySQL begge dele.
Resten af dette svar er spekulationer.
Grunden til, at ydeevnen "kun" er 300 gange langsommere, snarere end 200.000 gange langsommere, er på grund af overhead ved læsning af indekset. Faktisk er scanning af posterne ret hurtig sammenlignet med andre operationer, der er nødvendige.
Der er en grundlæggende forskel mellem tal og strenge, når det kommer til sammenligninger. Motoren kan bare se på bitrepræsentationerne af to tal og genkende, om de er ens eller forskellige. For strenge skal du desværre tage hensyn til kodning/sortering. Jeg tror, det er derfor, den skal se på værdierne.
Det er muligt, at hvis du havde 216.000 kopier af præcis den samme streng, så ville MySQL være i stand til at foretage optællingen ved hjælp af metadata i indekset. Med andre ord er indekseren smart nok til at bruge metadata til nøjagtige lighedssammenligninger. Men det er ikke smart nok at tage kodning i betragtning.