Mysql: ограничение «UNIQUE» для большой строки

Каким может быть возможный недостаток ограничения UNIQUE для большой строки (varchar) (примерно 100 символов или так) в MYSQL во время:

  • вставить фазу
  • фаза поиска (по другому первичному ключу)

Может ли длина запроса повлиять на производительность чтения/записи? (Помимо использования диска/памяти для ведения бухгалтерского учета).

Спасибо


person Harshit    schedule 15.03.2019    source источник


Ответы (1)


Несколько вопросов. Существует ограничение на размер столбца в индексе (191, 255, 767, 3072 и т. д., в зависимости от разных вещей).

Ваш столбец соответствует ограничениям.

Просто создайте ключ UNIQUE или PRIMARY для этого столбца. Есть небольшие проблемы с производительностью, но имейте в виду: Извлечение строки обходится дороже, чем любые проблемы с типом данных, связанные с ключом, используемым для ее поиска.

Ваш столбец не подходит.

Теперь обходные пути становятся уродливыми.

  • Префикс индекса (INDEX foo(50)) имеет ряд проблем и недостатков.
  • UNIQUE foo(50) совершенно неверно. Он объявляет, что первые 50 символов должны быть уникальными, не весь столбец.
  • Обходные пути с хэшированием строки (cf md5, sha1 и т.д.) имеют ряд проблем и неэффективны. Тем не менее, это может быть единственным жизнеспособным способом обеспечения уникальности длинной строки.

(Расскажу, если нужно.)

Выбор строки (при условии, что оператор проанализирован и доступен PRIMARY KEY).

  1. Разверните BTree, содержащую данные (и упорядоченные ПК). Это может включать перенос блока (или более) с диска в пул буферов.
  2. Разберите блок, чтобы найти строку. (В блоке, вероятно, десятки строк.)
  3. В какой-то момент процесса заблокируйте строку для чтения и/или заблокируйте каким-либо другим соединением, например, обновлением или удалением.
  4. Разберите строку, то есть разбейте ее на столбцы.
  5. Для получения любых необходимых текстовых/BLOB-столбцов обратитесь к незарегистрированному хранилищу. (Широкие столбцы не сохраняются вместе с мелкими элементами строки; они хранятся в других блоках.)
  6. Преобразование из внутреннего хранилища (не с выравниванием по словам, с прямым порядком байтов и т. д.) в нужный формат. (Небольшой объем кода процессора, но необходимый.)

Если следующим шагом является сравнение двух строк (для JOIN или ORDER BY), то простая подпрограмма вызывает сканирование любого количества символов. (Хорошо, большинство сопоставлений utf8 не являются «простыми».) И да, сравнение двух INT было бы быстрее.

person Rick James    schedule 15.03.2019
comment
Не могли бы вы уточнить: «Извлечение строки обходится дороже, чем любые проблемы с типом данных, связанные с ключом, используемым для ее поиска». - person Harshit; 16.03.2019
comment
@RickJames, не могли бы вы немного объяснить об этом For any text/blob columns needed, reach into the off-record storage и Convert from the internal storage into desired format - person swayamraina; 01.06.2019