Min fornemmelse er, at med en usigneret int og en varchar 40 (især varchar!) har du nu en KÆMPE primær nøgle, og den gør din indeksfil for stor til at passe ind i den RAM du har til Innodb_buffer_pool. Dette ville gøre InnoDB nødt til at stole på disken for at bytte indekssider, mens den søger, og det er MANGE disksøgninger og ikke meget CPU-arbejde.
En ting, jeg gjorde for et lignende problem, var at bruge noget mellem en virkelig naturlig nøgle og en surrogatnøgle. Vi ville tage de 2 felter, der faktisk er unikke (hvoraf det ene også var en varchar) og i applikationslaget ville lave en MD5-hash med fast bredde og bruge THAT som nøglen. Ja, det betyder mere arbejde for appen, men det giver en meget mindre indeksfil, da du ikke længere bruger et vilkårligt længdefelt.
ELLER, du kan bare bruge en server med tonsvis af RAM og se, om det får indekset til at passe i hukommelsen, men jeg kan altid godt lide at gøre 'smid hardware på det' til en sidste udvej :)