Есть php-скрипт, который добавляет в mysql-базу по несколько тысяч товаров из csv-файла.
При добавлении он должен проверить товар на уникальность по трем текстовым столбцам в базе (бренд и т.д.)
Тестирование показало, что этот этап занимает больше всего времени при загрузке файла (до 2 минут при 10 тыс товаров в файле). Включение составного индекса ничего не дало.
Появилась такая идея: mysql по числовым столбцам будет искать ведь намного быстрее, чем по текстовым. Что если эти текстовые поля хранить в виде чисел в трех числовых столбцах, или даже объединить в одно составное число и искать по одному числовому столбцу. Но для этого нужно придумать или подобрать алгоритм кодирования букв цифрами.
Суммарное количество букв в этих трех столбцах может доходить до 40. И если кодировать одну букву двумя цифрами (ведь букв в алфавите больше 10), то получится 40-значное число. Но даже тип BIGINT вместит только 19 знаков.

Существует ли кодирование текста в число, при котором можно закодировать 40 букв в тип INT?

А что если брать md5 хеш от индексируемых полей и хранить его в БД как BINARY(16)?
Возможны коллизии, конечно, но это можно предусмотреть в коде.

Этот ответ добавлен с нового Винграда - http://vingrad.com

Точно? Может что-то неправильно было сделано? 
Обычно, для отладки запросов используется функция EXPLAIN, она выводит все используемые запросом ключи. Обычно, даже если просто проиндексировать все поля, которые используются в where, уже, как правило, получается прирост в скорости.


crc32 от строковой конкатенации всех 3 полей. Или любую другую cache-функцию. 

ksnk, просто конкатенация может привести к ошибке.

например сделай конкатенацию 121 и 30, а если попадется 12 и 130 - результат конкатенации один, а индексы все же разные.

аналогично про твое предложение md5(a+b+c)

А вообще, при применении индексов, должна увеличиться скорость ... ну, неплохо бы посмотреть на результат выполнения EXPLAIN ...

Этот ответ добавлен с нового Винграда - http://vingrad.com

Конкатенация можеть дать одинаковый результат, да. И коллизия хеша тоже может случиться. Но, как я написал в первом посте, после выборки по хешу можно дополнительно проверить значения полей.

Вообще, конечно, было бы хорошо посмотреть на схему БД и на запросы к ней, которые использует автор. Можно тут - SQL Fiddle

Этот ответ добавлен с нового Винграда - http://vingrad.com