wanomgn

1. Хранить можно по разному. Можно, например, разбить таблицу на 2ⁿ таблиц по первым битам хэша (table_00, table_01, ... table_ff).
2. Хэш, как таковой, не гарантирует однозначного отображения, то есть вполне вероятен вариант, когда две разные строки будут иметь один и тот же хэш. Для n-битного хэша перебор 2^n/2 строк выдаст два одинаковых значения хэша с вероятностью 63% (парадокс дней рождения). По таблице можете оценить, какая вероятность коллизии будет для вашего количества строк при разной длине хэша.

Уточните пожалуйста условия задачи.
Что за хеши, от чего они, зачем, какой к ним планируется доступ.
Существует огромное количество разных хеш функций.
google "хеш функции"

т.к 20 символов в bigint не влезут, вам придется хранить это дело в текстовом виде, а тут однозначно лучше использовать символьный хеш.
Может быть как то его дополнительно пережимать в непечатные символы и хранить как BINARY какой нибудь

И да, миллиарды в одной таблицe mysql это уже экстрим :)

UPD

таблица "справочник" из двух столбцов.
1.хэш
2.текст до 200 символов.
Есть готовый хэш. Дергаем таблицу что бы узнать какой строке соответствует этот хэш?

1. Не надо держать в одной таблице контент и хеш. Правильно иметь 2 таблицы: хеш,ид_текста; ид_текста,текст
2. хеш в любом случае не дает ответа "точно да". он дает ответ "может быть да"
исходя из этого я бы выбрал какую то хеш функцию которая влазит по длине в UNSIGNED INT, и дополнительно проверял результат уже с текстом.