La mia impressione è che con un int non firmato e un varchar 40 (soprattutto il varchar!) Ora hai una chiave primaria ENORME e sta rendendo il tuo file di indice troppo grande per adattarsi a qualsiasi RAM tu abbia per Innodb_buffer_pool. Ciò farebbe sì che InnoDB debba fare affidamento sul disco per scambiare le pagine dell'indice durante la ricerca e questo significa MOLTE ricerche su disco e non molto lavoro sulla CPU.
Una cosa che ho fatto per un problema simile è usare qualcosa tra una chiave veramente naturale e una chiave surrogata. Prenderemmo i 2 campi che sono effettivamente unici (uno dei quali era anche un varchar) e nel livello dell'applicazione creeremo un hash MD5 a larghezza fissa e useremo QUELLO come chiave. Sì, significa più lavoro per l'app, ma crea un file di indice molto più piccolo poiché non stai più utilizzando un campo di lunghezza arbitraria.
OPPURE, potresti semplicemente usare un server con tonnellate di RAM e vedere se questo fa rientrare l'indice nella memoria, ma mi piace sempre fare "lancia l'hardware al suo posto" come ultima risorsa :)
