There are plenty of discussions on the benefits and drawbacks of using hashes as primary keys, but in my case I have a database of webpages that I need to look up by address, and these addresses are longer than the maximum text index length. Also, it's quite the performance hit to index on
Until recently I was using MD5 checksums to look up addresses due to the speed of the function and a limited need for protection against hash collisions. But this specific application has the potential for the submission of "database-malicious URLs" that are invalid*, but crafted with the same checksum as valid URLs.
Is there a big performance hit switching from a primary key using 128-bit MD5 to a primary key of SHA-224+ (the smallest "unbroken" SHA-based hash I can find)? Should I index these as byte arrays or chars? Or is there another solution if I need reverse lookup AND collision security?
My DBMS is MySQL 5.7, but I would consider switching if there's an amazing solution in another DBMS with similar resource requirements that is freely available.
*Invalid as in technically resolvable, but not a "real" URL, i.e. http://example.com/reallyLongStringThatYieldsAHashCollisionWithARealURL