Ошибка MySQL: спецификация ключа без длины ключа

Вы должны определить, какую ведущую часть столбца TEXT вы хотите индексировать.

InnoDB имеет ограничение 768 байтов на индексный ключ, и вы не сможете создать индекс дольше этого.

Это будет нормально работать:

CREATE TABLE t_length (
      mydata TEXT NOT NULL,
      KEY ix_length_mydata (mydata(255)))
    ENGINE=InnoDB;

Обратите внимание, что максимальное значение размера ключа зависит от кодировки столбца. Символы 767 для однобайтовой кодировки типа LATIN1 и только 255 символов для UTF8 (MySQL использует только BMP, который требует не более 3 байтов на символ)

Если вам нужен весь столбец PRIMARY KEY, вычислите хеш SHA1 или MD5 и используйте его как PRIMARY KEY.

Вы можете указать длину ключа в запросе alter table, например:

alter table authors ADD UNIQUE(name_first(20), name_second(20));

MySQL запрещает индексирование полного значения столбцов BLOB, TEXT и long VARCHAR, потому что данные, которые они содержат, могут быть огромными, а неявно индекс DB будет большим, что не означает выгоды от индекса.

MySQL требует, чтобы вы определяли первые N символов, которые нужно индексировать, и трюк состоит в том, чтобы выбрать число N, которое достаточно долго, чтобы обеспечить хорошую избирательность, но достаточно короткое, чтобы сэкономить место. Префикс должен быть достаточно длинным, чтобы сделать индекс почти таким же полезным, как если бы вы индексировали весь столбец.

Прежде чем идти дальше, давайте определим некоторые важные термины. Селективность индекса - это отношение всех отдельных индексированных значений и общего количества строк. Вот один пример тестовой таблицы:

+-----+-----------+
| id  | value     |
+-----+-----------+
| 1   | abc       |
| 2   | abd       |
| 3   | adg       |
+-----+-----------+

Если мы индексируем только первый символ (N = 1), тогда таблица индексов будет выглядеть как следующая таблица:

+---------------+-----------+
| indexedValue  | rows      |
+---------------+-----------+
| a             | 1,2,3     |
+---------------+-----------+

В этом случае селективность индекса равна IS = 1/3 = 0,33.

Посмотрим, что произойдет, если мы увеличим число индексированных символов до двух (N = 2).

+---------------+-----------+
| indexedValue  | rows      |
+---------------+-----------+
| ab             | 1,2      |
| ad             | 3        |
+---------------+-----------+

В этом сценарии IS = 2/3 = 0,66, что означает увеличение селективности индекса, но мы также увеличили размер индекса. Трюк состоит в том, чтобы найти минимальное число N, которое приведет к максимальной селективности индекса.

Существует два подхода, которые вы можете выполнить для расчета таблицы базы данных. Я сделаю демонстрацию на этой дампе базы данных.

Предположим, мы хотим добавить столбец last_name в таблице сотрудников в индекс, и мы хотим определить наименьшее число N, которое будет обеспечивать лучшую селективность индекса.

Сначала определим наиболее часто используемые фамилии:

select count(*) as cnt, last_name 
from employees 
group by employees.last_name 
order by cnt

+-----+-------------+
| cnt | last_name   |
+-----+-------------+
| 226 | Baba        |
| 223 | Coorg       |
| 223 | Gelosh      |
| 222 | Farris      |
| 222 | Sudbeck     |
| 221 | Adachi      |
| 220 | Osgood      |
| 218 | Neiman      |
| 218 | Mandell     |
| 218 | Masada      |
| 217 | Boudaillier |
| 217 | Wendorf     |
| 216 | Pettis      |
| 216 | Solares     |
| 216 | Mahnke      |
+-----+-------------+
15 rows in set (0.64 sec)

Как вы можете видеть, последнее имя Baba является самым частым. Теперь мы собираемся найти наиболее часто встречающиеся префиксы last_name, начиная с пятибуквенных префиксов.

+-----+--------+
| cnt | prefix |
+-----+--------+
| 794 | Schaa  |
| 758 | Mande  |
| 711 | Schwa  |
| 562 | Angel  |
| 561 | Gecse  |
| 555 | Delgr  |
| 550 | Berna  |
| 547 | Peter  |
| 543 | Cappe  |
| 539 | Stran  |
| 534 | Canna  |
| 485 | Georg  |
| 417 | Neima  |
| 398 | Petti  |
| 398 | Duclo  |
+-----+--------+
15 rows in set (0.55 sec)

В каждом префиксе гораздо больше случаев, что означает, что мы должны увеличить число N до тех пор, пока значения не будут такими же, как в предыдущем примере.

Вот результаты для N = 9

select count(*) as cnt, left(last_name,9) as prefix 
from employees 
group by prefix 
order by cnt desc 
limit 0,15;

+-----+-----------+
| cnt | prefix    |
+-----+-----------+
| 336 | Schwartzb |
| 226 | Baba      |
| 223 | Coorg     |
| 223 | Gelosh    |
| 222 | Sudbeck   |
| 222 | Farris    |
| 221 | Adachi    |
| 220 | Osgood    |
| 218 | Mandell   |
| 218 | Neiman    |
| 218 | Masada    |
| 217 | Wendorf   |
| 217 | Boudailli |
| 216 | Cummings  |
| 216 | Pettis    |
+-----+-----------+

Вот результаты для N = 10.

+-----+------------+
| cnt | prefix     |
+-----+------------+
| 226 | Baba       |
| 223 | Coorg      |
| 223 | Gelosh     |
| 222 | Sudbeck    |
| 222 | Farris     |
| 221 | Adachi     |
| 220 | Osgood     |
| 218 | Mandell    |
| 218 | Neiman     |
| 218 | Masada     |
| 217 | Wendorf    |
| 217 | Boudaillie |
| 216 | Cummings   |
| 216 | Pettis     |
| 216 | Solares    |
+-----+------------+
15 rows in set (0.56 sec)

Это очень хорошие результаты. Это означает, что мы можем сделать индекс в столбце last_name с индексированием только первых 10 символов. В столбце определения таблицы last_name определяется как VARCHAR(16), и это означает, что мы сохранили 6 байтов (или больше, если есть символы UTF8 от имени) для каждой записи. В этой таблице 1637 различных значений, умноженных на 6 байт, составляет около 9 КБ, и представьте, как это число будет расти, если наша таблица содержит миллион строк.

Вы можете прочитать другие способы вычисления числа N в моем сообщении Префиксные индексы в MySQL.

alter table authors ADD UNIQUE(name_first(767), name_second(767));

ПРИМЕЧАНИЕ: 767 - количество символов, до которых MySQL будет индексировать столбцы при работе с индексами blob/text

Ссылка: http://dev.mysql.com/doc/refman/5.7/en/innodb-restrictions.html

Не имеет длинных значений в качестве первичного ключа. Это разрушит вашу работу. См. Руководство по mysql, раздел 13.6.13 "Настройка производительности и устранение неполадок InnoDB".

Вместо этого, иметь суррогатный ключ int как первичный (с auto_increment), а ваш ключ loong как вторичный UNIQUE.

Еще один отличный способ справиться с этим - создать поле TEXT без уникального ограничения и добавить уникальное поле VARCHAR для сиблинга, которое содержит дайджест (MD5, SHA1 и т.д.) поля TEXT. Вычислите и сохраните дайджест во всем поле ТЕКСТ, когда вы вставляете или обновляете поле ТЕКСТ, тогда у вас есть ограничение уникальности во всем поле ТЕКСТ (а не какая-то ведущая часть), которую можно быстро найти.

Добавьте еще один столбец varChar (255) (по умолчанию как пустая строка не null), чтобы удерживать переполнение, когда 255 символов недостаточно, и измените этот PK на использование обоих столбцов. Однако это не похоже на хорошо спроектированную схему базы данных, и я бы рекомендовал получить модель данных данных для просмотра того, что у вас есть, с целью рефакторинга для большей нормализации.

Используйте это

@Id
@Column(name = "userEmailId", length=100)
private String userEmailId;

Решение проблемы заключается в том, что в вашем операторе CREATE TABLE вы можете добавить ограничение UNIQUE ( problemtextfield(300) ) после того, как столбец создаст определения, чтобы указать длину key символов 300 для поля TEXT, для пример. Тогда первые 300 символы поля problemtextfield TEXT должны быть уникальными, и любые различия после этого будут проигнорированы.

Кроме того, если вы хотите использовать индекс в этом поле, вы должны использовать механизм хранения MyISAM и индексный тип FULLTEXT.