Slow MySQL searching from millions record
hash is unique?  If so, change it from KEY to PRIMARY KEY.  That will save some space, but not change the performance much.

It sounds like your innodb_buffer_pool_size is small.  It should be set to about 70% of available RAM.

Let's analyze what is happening.  You have about 100 hashes and a KEY (of any type) on hash.  It will reach into the key about 100 times in 100 different locations.  ("MRR" is involved here, but those details are not very relevant.)  Each lookup of a hash value in the BTree-organized index probably does not find the desired block in the buffer_pool, so it has to hit the disk to get it.  This means about 100 disk hits.  Assuming you have a cheap disk, these hits will take a total of about 1 second.  (Sorry, I can't explain 4 seconds, unless the cache was "cold" and index blocks needed to be fetched, too.)

So, what will a bigger buffer_pool do?  Eventually (as your queries cache more and more of the table), those 100 will be "cache hits" and not have to go to disk.  And the speed will be sub-second.

Your table is probably under 400MB (regardless of whether you take someone's advice on PRIMARY KEY).  You should be able to afford a buffer_pool bigger than that.