Moje przeczucie jest takie, że z niepodpisanym int i varchar 40 (zwłaszcza varchar!) masz teraz OGROMNY klucz podstawowy i sprawia to, że twój plik indeksu jest zbyt duży, aby zmieścić się w dowolnej pamięci RAM, którą masz dla Innodb_buffer_pool. To spowodowałoby, że InnoDB musiałby polegać na dysku, aby wymieniać strony indeksu podczas wyszukiwania, a to jest DUŻO poszukiwań dysku, a nie dużo pracy procesora.
Jedną z rzeczy, które zrobiłem w przypadku podobnego problemu, jest użycie czegoś pomiędzy kluczem prawdziwie naturalnym a kluczem zastępczym. Wzięlibyśmy 2 pola, które są faktycznie unikalne (z których jedno było również varchar) i w warstwie aplikacji utworzylibyśmy hash MD5 o stałej szerokości i użylibyśmy TEGO jako klucza. Tak, oznacza to więcej pracy dla aplikacji, ale powoduje to znacznie mniejszy plik indeksu, ponieważ nie używasz już pola arbitralnej długości.
LUB możesz po prostu użyć serwera z tonami pamięci RAM i sprawdzić, czy indeks zmieści się w pamięci, ale zawsze lubię robić „rzucanie sprzętu” w ostateczności :)
