Mysql - индекс длинной строки против индекса управления суммой md5 в отдельном столбце [дубликат]

Принятый ответ спас меня (спасибо, Билл !!!), но я столкнулся с другой связанной проблемой, просто хотел предоставить некоторые детали моего опыта -

После перехода на MySQL 8.0.11, У меня возникла такая же проблема, как и при использовании функции PHP mysqli_connect(). В моем каталоге MySQL (в моем случае usr/local/mysql) я создал файл my.cnf, добавил контент в принятом ответе, а затем перезапустил сервер MySQL. Однако это вызвало новую ошибку:

mysqli_connect(): The server requested authentication method unknown to the client [caching_sha2_password]

Я добавил строку default_authentication_plugin = mysql_native_password, поэтому my.cnf теперь выглядит так:

[client]
default-character-set=utf8

[mysql]
default-character-set=utf8

[mysqld]
collation-server = utf8_unicode_ci
character-set-server = utf8
default_authentication_plugin = mysql_native_password

, и мне было хорошо идти !

Для дополнительной справки: https://github.com/laradock/laradock/issues/1392

3
задан Gury Max 8 March 2013 в 15:20
поделиться

2 ответа

Как мне было предложено в комментариях, как я это разрешу, я напишу это как ответ.

В такой ситуации можно предположить ошибки в дизайне приложения. Подумайте, что это значит.

У вас есть текст, о котором вы не можете указать длину заранее и которая может быть чрезвычайно длинной (до 64k), из которой вы хотите сохранить уникальность. Представьте, что такое количество данных разделено на отдельные ключи и составление составного индекса для генерации уникальности. Это то, что вы пытаетесь сделать. Для целых чисел это будет индекс из 16000 целых чисел, объединенный в составном индексе.

Рассмотрим далее, что поля типа CHARACTER (CHAR, VARCHAR, TEXT) интерпретируются путем кодирования, что еще более усложняет проблему.

Я бы очень рекомендовал разбить данные так или иначе. Это не только освобождает СУБД от включения символьных блоков переменной длины, но также может дать некоторую возможность генерации составных ключей над частями данных. Возможно, вы даже можете найти лучшее решение для хранения данных.

Если у вас есть вопросы, я бы предложил опубликовать таблицу и / или структуру базы данных и объяснить, какие логические данные содержит поле TEXT, и почему вы подумайте, что это должно быть уникальным.

3
ответ дан 0xCAFEBABE 22 August 2018 в 21:54
поделиться

Это почти полно. Есть шанс (Парадокс дня рождения), что произойдет столкновение с хешем, поэтому одного индекса UNIQUE недостаточно.

Лучше использовать хэш вместе со сравнением, чтобы быть полностью безопасным .

SELECT COUNT(*) FROM table
WHERE md5hash = MD5(text)
AND textvalue = text

Это может быть обернуто в INSERT или UPDATE TRIGGER - или, возможно, даже STORED PROCEDUR для легкой проверки.

Посмотрите на this Stack Overflow question для примера хэш-столкновения.

1
ответ дан Community 22 August 2018 в 21:54
поделиться
  • 1
    Имейте в виду, что если строки являются значимым текстом, следуя некоторым ограничительным правилам, таким как те, которые определяют естественный язык, вероятность хеш-столкновения становится мала. – eggyal 8 March 2013 в 16:16
  • 2
    @eggyal Я полностью согласен, очень очень маленький ... но не невозможно. – Steve 8 March 2013 в 16:18
Другие вопросы по тегам:

Похожие вопросы: