Mijn vermoeden is dat met een niet-ondertekende int en een varchar 40 (vooral de varchar!) je nu een ENORME primaire sleutel hebt en het maakt je indexbestand te groot om te passen in het RAM-geheugen dat je hebt voor Innodb_buffer_pool. Dit zou ervoor zorgen dat InnoDB op schijf moet vertrouwen om indexpagina's te wisselen terwijl het zoekt en dat is VEEL schijfzoekacties en niet veel CPU-werk.
Een ding dat ik voor een soortgelijk probleem deed, is iets gebruiken tussen een echt natuurlijke sleutel en een surrogaatsleutel. We zouden de 2 velden nemen die eigenlijk uniek zijn (waarvan er één ook een varchar was) en in de applicatielaag zouden we een MD5-hash met vaste breedte maken en DAT als de sleutel gebruiken. Ja, het betekent meer werk voor de app, maar het zorgt voor een veel kleiner indexbestand omdat je niet langer een veld met een willekeurige lengte gebruikt.
OF, je zou gewoon een server met tonnen RAM kunnen gebruiken en kijken of de index daardoor in het geheugen past, maar ik vind het altijd leuk om 'hardware erop te gooien' een laatste redmiddel :)