MySQL хэши для оптимизации SELECT?

Question

[PigData]

Задача - сделать хэш по нескольким полям для ускорения выборки, в базе около 50 миллионов строк, существенно не увеличивая размер базы, сведя к минимуму коллизии, без граблей с 32/64 битными системами.

Какой тип/размер кэша, тип поля посоветуете. Копал в сторону CRC** и поля UNSIGNED INT, но боюсь что будет достаточно много коллизий и проблемы на 32/64 битных системах.

Comments

[Arman]

а задачу какую делаете? должны быть уникальные записи?

[PigData]

Скажем допустимо несколько десятков-сотен коллизий, но если счет пойдет на тысячи уже не совсем мой вариант.

[zkrvndm]

Ты чуть ранее задавал вопрос и пока я писал ответ, успел удалить его. Мой ответ:

Используй AlertifyJS:
https://alertifyjs.com
Для просмотра демо пролистай ниже и кликай кнопки Run Example.

Answer 1

[Anton B]

Как-то сталкивался с похожей задачей, при отправке смс сообщений, нужно было проверять что такое сообщение уже было отправлено и не стоит отправлять его заново. Тогда делал CRC (пользователь, сообщение, что-то еще). Для моей задачи этого хватило, в моем случае было не фатально если пользователь вдруг еще раз получит похожее сообщение.

Если же повторение записей фатально, то только уникальный индекс по полям даст 100% защиту, но будет очень тяжелым. Или же отдельное поле с sha1 хешем, вроде в sha1 вероятность коллизии крайне мала https://crypto.stackexchange.com/questions/2583/is...