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