MySQL усекает составленный уникальный индекс до 64 символов

Question

У меня проблемы с составленным уникальным ключом MySQL.

Он состоит из URL, целочисленного значения и поля даты.

Но когда я пытаюсь вставить строку, я получаю исключение:

Caused by: com.mysql.jdbc.exceptions.jdbc4.MySQLIntegrityConstraintViolationException: Duplicate entry 'http://cars.auto.ru/cars/used/sale/16152870-c13f1.html-2012-02-1' for key 'one_a_day_idx'

Как видите, составной индекс был усечен до 64 символов, и из-за этого он больше не является уникальным (я получаю данные из внешнего источника один раз в день)

Но самое запутанное, что запись была вставлена, хотя было брошено исключение о нарушении ограничения

Был похожий вопрос здесь , но единственным советом было использовать SHOW CREATE TABLE, чтобы узнать фактическую длину индекса.

Показать создание таблиц показывает это:

| auto_ru_sale | CREATE TABLE `auto_ru_sale` (
  `ID` int(11) NOT NULL AUTO_INCREMENT,
  `template` int(11) NOT NULL,
  `region` varchar(128) NOT NULL,
  `URI` varchar(128) NOT NULL,
  `subType` varchar(128) NOT NULL,
  `cost` int(11) NOT NULL,
  `productionYear` int(11) NOT NULL,
  `engineVolume` int(11) NOT NULL,
  `transmitionType` varchar(1) NOT NULL,
  `run` int(11) NOT NULL,
  `evaluationDate` date NOT NULL,
  PRIMARY KEY (`ID`),
  UNIQUE KEY `one_a_day_idx` (`template`,`URI`,`evaluationDate`),
  KEY `prodyear_idx` (`productionYear`),
  KEY `evdate_idx` (`evaluationDate`),
  CONSTRAINT `auto_ru_sale_ibfk_1` FOREIGN KEY (`template`) REFERENCES `auto_ru_
datatemplate` (`ID`) ON DELETE CASCADE
) ENGINE=InnoDB AUTO_INCREMENT=127012 DEFAULT CHARSET=utf8 |

Итак, я не вижу никаких ограничений на длину индекса.

Большое спасибо всем, кто может помочь с этой проблемой.

Answer 1

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

Создать таблицу, то есть URI (URI_id INT UNSIGNED PK AI, URI VARCHAR (128) NOT NULL, UNIQUE KEY (URI)) и измените auto_ru_sale для хранения uri_id вместо URI

Это будет означать, что ключ становится ключом INT, INT, DATE, что будет более эффективным.Ваш размер таблицы уменьшится из-за меньшего количества дубликатов.В целом нормализация выгодна.

Я бы также посоветовал применить то же самое к полю "регион", так как предположил, что в нем также много дублирующих данных.

Answer 2

Я столкнулся с той же проблемой сегодня.

Проблема в моем случае заключалась в том, что индекс уникальности на самом деле был длиннее 64 символов, но в сообщении об ошибке показаны только первые 64 символа.Я думаю, что здесь тот же случай.

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