CHAR is space inefficient but much faster than varchar for select.

In this case, it's more space efficient, since you know that a MD5 string will always be a certain length l for a given encoding. The CHAR field will only need to store l characters, whereas VARCHAR will need to store l + the length of l. So I don't see any benefit to using VARCHAR in this case.

Some databases may support bit vectors (like PostgreSQL's BIT type). In that case, you'll only need 16 bytes of storage space (assuming you use a non-VARYING bit field) compared to 32 bytes for hex encoding (assuming an 8-bit text encoding standard like ASCII (ok, technically 7-bit, but who actually stores it like that anymore?)). However, it's not portable to databases that don't support that type (like MySQL).