У меня есть карта от строк до целых чисел. Для хранения этой карты в базе данных MySQL, я создал следующую таблицу:
CREATE TABLE map(
Argument TEXT NOT NULL,
Image INTEGER NOT NULL
)
Я выбрал Тип текста для аргумента, потому что его длина непредсказуема, в настоящее время самая длинная запись имеет 2 290 символов, и средняя длина является 88 символами.
После того, как я встретил проблемы производительности, я пытался включить индекс Argument
столбец, но найденный, что я должен для определения длины, так для предотвращения этого ограничения, я добавил новый целочисленный столбец, содержащий значения хэш-функции (md5 или иначе) значений столбцов Аргумента.
ALTER TABLE map ADD COLUMN ArgumentHash INTEGER;
И объединенный индекс
CREATE INDEX argument_index USING HASH ON map(ArgumentHash, Argument(80));
С этого времени проблемы с производительностью исчезли. Я хотел бы спросить, является ли это корректным способом решить эту проблему.
Я не думаю, что есть "правильный" способ, это зависит от того, для чего вы используете столбец.
По моему опыту, редко приходится / хотеть выбирать в большом текстовом столбце; текст обычно представляет собой данные, полученные с помощью другого ключа (если он не проиндексирован каким-либо другим способом - например, полный текст, Lucene - но, похоже, это не то, что вы делаете)
Если вам действительно нужно точное совпадение в большом поле может быть более эффективным использование хеша, так как это, вероятно, позволит вам сохранить индекс меньшего размера. Я предполагаю, что если вам нужно использовать размер индекса больше, чем размер хэша (зависит от того, насколько близко к началу ТЕКСТА обычно различаются значения), используйте хеш.
Лучше всего попробовать и посмотреть. Профилируйте оба подхода с репрезентативными данными и узнайте.