Olika sökstrategier är meningsfulla för olika data. I synnerhet måste indexskanningar (som intervall) ofta göra en sökning för att faktiskt läsa raden. Någon gång går det långsammare att göra alla dessa sökningar än att inte använda indexet alls.
Ta ett trivialt exempel, en tabell med tre kolumner:id (primärnyckel), namn (indexerat), födelsedag. Säg att den har mycket data. Om du ber MySQL att leta efter Bobs födelsedag kan den göra det ganska snabbt:först hittar den Bob i namnindexet (detta tar några sökningar, log(n) där n är radantalet), sedan ytterligare en sökning för att läs den faktiska raden i datafilen och läs födelsedagen från den. Det är väldigt snabbt och mycket snabbare än att skanna hela tabellen.
Överväg sedan att göra ett name like 'Z%' . Det är förmodligen en ganska liten del av bordet. Så det är fortfarande snabbare att hitta var Z:en börjar i namnindexet, och sök sedan datafilen för var och en för att läsa raden. (Detta är en räckviddsskanning).
Slutligen, överväg att fråga efter alla namn som börjar med M-Z. Det är förmodligen ungefär hälften av uppgifterna. Den kan göra en räckviddsskanning och sedan mycket av sökningar, men att söka slumpmässigt över datafilen med det slutliga målet att läsa halva raderna är inte optimalt:det skulle vara snabbare att bara göra en stor sekventiell läsning över datafilen. Så i det här fallet kommer indexet att ignoreras.
Det här är vad du ser – förutom i ditt fall finns det en annan nyckel som den kan falla tillbaka på. (Det är också möjligt att det faktiskt kan använda datumindexet om det inte hade det andra, det bör välja vilket index som är snabbast. Se upp att MySQL:s optimerare ofta gör fel i detta.)
Så kort sagt, detta förväntas. En fråga säger inte hur för att hämta data, snarare står det vad data att hämta. Databasens optimerare är tänkt att hitta det snabbaste sättet att hämta den.
Du kan hitta ett index på båda kolumner, i ordningen (public_key,created_on_date) är att föredra i båda fallen, och påskyndar din fråga. Detta beror på att MySQL bara kan använda ett index per tabell (per fråga). Dessutom går datumet i slutet eftersom en intervallsökning endast kan göras effektivt på den sista kolumnen i ett index.
[InnoDB har faktiskt ett annat lager av inriktning, tror jag, men det skulle bara förvirra poängen. Det gör ingen skillnad på förklaringen.]