Форум пользователей MySQL

Добрый день!

md5 может существовать в разных видах:

- 16 байт (по своей природе)
- либо 2 числа BIGINT UNSIGNED (по 8 байт)
- либо 32 символа.

В связи с эти стоит вопрос - как хранить md5 в базе данных так, чтобы обеспечить максимальную скорость обработки запросов SELECT по ключу который есть md5, ну и... и по возможности минимальное использование памяти - оперативной и дисковой....

###############
Детали такие:
###############

Есть таблица desc в БД  (InnoDB):

       id - Primary key       text - BLOB


id должно быть типа md5.

В таблице предполагается хранить... скажем 1 200 000 записей

Предполагается делать выборку данных  из таблицы:

SELECT text FROM desc WHERE id = "<реальный md5 в каком то виде>"


Следовательно нужен индекс по md5.

Какой способ выбрать чтобы хранить md5 в базе?


###############
ВАРИАНТЫ
###############

Я так понимаю, существуют следующие варианты:

###
1. Классический
###
CHAR(32)

ПЛОХО т.к.

Индекс будет занимать много места на диске - 32 байта. Больше чтения с диска - меньше скорость. Больше места в памяти.

Неполный индекс CHAR(20)... Что он даст....

ХОРОШО:

Удобно работать с таким полем...

###
2. Сомнительный
###

Как 2 числа
BIGINT md5_part1, BIGINT md5_part2


PRIMARY KEY тогда будет (md5_part1, md5_part2)

ХОРОШО: уже 16 байт на диске, а не 32.

ПЛОХО:

1. не очень удобно с таким индексом работать из программ
2. НЕ понятно, будет ли такой индекс эффективен. или хотя бы эффективнее чем неполный индекс по CHAR(16) а не 32 из варианта 1.

###
3.  С параноидальными сомнениями.
###

BINARY(16)

ПЛОХО: Есть подозрение, что число BIGINT машиной обрабатывается быстрее чем 8 байт бинарных данных. И индекс по BIGINT
поэтому может оказаться более быстрым по своей природе, чем индекс по BINARY(8).

Суть подозрений в том, что INT обрабатывается вероятно машиной как число, т.е. 4 или 8 байт (x64) за одну команду - сложить, вычесть и т.п. Т.е. на шыну данных выставляется 32 бита... или 64...

А вот как  BINARY обрабатывается, если оно во внутренней форме не преобразовывается к INT - я не могу сказать.
А вдруг как 8 раз по 8 бит...

###
4.  Странный
###


В документации написано, что INT это строго 8 байт.

Но у меня под виндой на миске 5.1.24-rc-community

прокатывает:

mysql> create table asdf (id int(16) UNSIGNED PRIMARY KEY, name BLOB);
Query OK, 0 rows affected (0.22 sec)

mysql> describe asdf;
+-------+------------------+------+-----+---------+-------+
| Field | Type             | Null | Key | Default | Extra |
+-------+------------------+------+-----+---------+-------+
| id    | int(16) unsigned | NO   | PRI | NULL    |       |
| name  | blob             | YES  |     | NULL    |       |
+-------+------------------+------+-----+---------+-------+
2 rows in set (0.00 sec)


Как это понимать???

Либо можно хранить INT(16)? либо миска внутри все сама приводит к BINARY.

Но это врядли т.к., когда я делаю CREATE TABLE ( ... BIGINT ... )

и затем describe таблицы, миска пишет, что поле в созданной таблице это INT(20)!


Вот как то так... Как бы вы хранили md5 в связи с выше сказанным, и что такое int(16) которое работает, если знаете...