Min gissning är att med en osignerad int och en varchar 40 (särskilt varchar!) har du nu en ENORM primärnyckel och den gör din indexfil för stor för att passa i vilket RAM du än har för Innodb_buffer_pool. Detta skulle göra att InnoDB måste förlita sig på disk för att byta indexsidor när den söker och det är MYCKET disksökningar och inte mycket CPU-arbete.
En sak jag gjorde för ett liknande problem är att använda något mellan en verkligt naturlig nyckel och en surrogatnyckel. Vi skulle ta de 2 fälten som faktiskt är unika (varav det ena också var en varchar) och i applikationslagret skulle vi göra en MD5-hash med fast bredd och använda THAT som nyckel. Ja, det innebär mer arbete för appen men det ger en mycket mindre indexfil eftersom du inte längre använder ett godtyckligt längdfält.
ELLER, du kan bara använda en server med massor av RAM och se om det gör att indexet passar i minnet, men jag gillar alltid att göra "kasta hårdvara" till en sista utväg :)