Несколько вопросов. Существует ограничение на размер столбца в индексе (191, 255, 767, 3072 и т. д., в зависимости от разных вещей).
Ваш столбец соответствует ограничениям.
Просто создайте ключ UNIQUE
или PRIMARY
для этого столбца. Есть небольшие проблемы с производительностью, но имейте в виду: Извлечение строки обходится дороже, чем любые проблемы с типом данных, связанные с ключом, используемым для ее поиска.
Ваш столбец не подходит.
Теперь обходные пути становятся уродливыми.
- Префикс индекса (
INDEX foo(50)
) имеет ряд проблем и недостатков.
UNIQUE foo(50)
совершенно неверно. Он объявляет, что первые 50 символов должны быть уникальными, не весь столбец.
- Обходные пути с хэшированием строки (cf md5, sha1 и т.д.) имеют ряд проблем и неэффективны. Тем не менее, это может быть единственным жизнеспособным способом обеспечения уникальности длинной строки.
(Расскажу, если нужно.)
Выбор строки (при условии, что оператор проанализирован и доступен PRIMARY KEY
).
- Разверните BTree, содержащую данные (и упорядоченные ПК). Это может включать перенос блока (или более) с диска в пул буферов.
- Разберите блок, чтобы найти строку. (В блоке, вероятно, десятки строк.)
- В какой-то момент процесса заблокируйте строку для чтения и/или заблокируйте каким-либо другим соединением, например, обновлением или удалением.
- Разберите строку, то есть разбейте ее на столбцы.
- Для получения любых необходимых текстовых/BLOB-столбцов обратитесь к незарегистрированному хранилищу. (Широкие столбцы не сохраняются вместе с мелкими элементами строки; они хранятся в других блоках.)
- Преобразование из внутреннего хранилища (не с выравниванием по словам, с прямым порядком байтов и т. д.) в нужный формат. (Небольшой объем кода процессора, но необходимый.)
Если следующим шагом является сравнение двух строк (для JOIN или ORDER BY), то простая подпрограмма вызывает сканирование любого количества символов. (Хорошо, большинство сопоставлений utf8 не являются «простыми».) И да, сравнение двух INT было бы быстрее.
person
Rick James
schedule
15.03.2019