Производительность сопоставления ...
..._bin
имеет наименьшее количество дел, поэтому они самые быстрые.
ascii_...
проверяет, используете ли вы только 7 бит; так быстро.
..._general_ci
проверяет только байты, без комбинации байтов. Пример: немецкий ß
<> 'ss', в отличие от большинства других сопоставлений.
utf8_...
и utf8mb4_...
проверяют байты на правильность кодирования.
Между тем, MySQL 8.0 сделал сопоставление utf8mb4_...
«на порядок быстрее», чем 5.7.
Но я обычно нахожу, что другие соображения важнее в любой операции в MySQL.
Другой пример этого ... SELECT ... function(foo) ...
- Стоимость оценки функции, как правило, незначительна по сравнению со стоимостью выборки строки. Итак, я сконцентрируюсь на том, как оптимизировать выборку строк.
Что касается хэшей, ... Это зависит от того, возвращает ли функция шестнадцатеричную строку или набор байтов ...
- Hex: используйте
CHARACTER SET ascii COLLATION ascii_bin (or ascii_ci)
...ci
сделает складывание корпуса, тем самым будет более прощающим; это, вероятно, «правильное» сопоставление для дела.
- байт: используйте тип данных
BINARY
; что примерно эквивалентно CHAR CHARACTER SET binary
.
Что касается использования BINARY
против VARBINARY
или CHAR
против VARCHAR
, то это должно контролироваться тем, возвращает ли функция результат фиксированной длины. Например:
MD5('asdfb') --> '23c42e11237c24b5b4e01513916dab4a'
возвращает ровно 32 шестнадцатеричных байта, поэтому CHAR(32) COLLATION ascii_ci
является «лучшим».
Но вы можете сэкономить место, используя BINARY(16)
(без сортировки) и вставив в него UNHEX(MD5('asdfb'))
.
UUID() --> '161b6a10-e17f-11e8-bcc6-80fa5b3669ce'
, у которого есть несколько штрихов, от которых нужно избавиться. В противном случае это CHAR(36)
или BINARY(16)
.