MySQL Duplicate запись '16777216' для ключа 1 Ошибка

Question

MySQL Duplicate запись '16777216' для ключа 1 Ошибка

0

У меня есть база данных MySQL, заполняемая приложением С#, массовая загрузка записей в масштабе более 100 миллионов записей. После импорта этих записей в данные используются дополнительные аналитические и другие инструменты оценки. Когда я выбираю меньший поднабор данных, записи становятся все точнее, однако, когда я использую полный набор данных, как только запись # 16777216 достигнута, эта ошибка возникает. До того, как у меня были уникальные первичные настройки, дублирующие записи идентификаторов создавались здесь и там, но все данные поступали. Однако, если учесть дублированные записи, дальнейшая обработка приводила к неправильным результатам.

Мой вопрос прост, кто-нибудь слышал об этой проблеме раньше, и если да, то что происходит? Является ли это ошибкой в моей версии MySQL? Я запускаю MySQL 5.0.67 в Windows XP.

Спасибо большое!

Dan McKinnon 05 дек. 2010, в 04:18

Источник

0

16777216 - максимальное количество значений в 24-битном целом числе. Каков размер значения, которое вы используете в столбцах PRIMARY и UNIQUE?
Billy ONeal 05 дек. 2010, в 03:06
0

поле первичного ключа является первичным ключом BIGINT, а не нулевым автоприращением без знака.
Dan McKinnon 05 дек. 2010, в 03:18
0

я нахожу это невероятным совпадением, что 16777216 будет записью, которая продолжает терпеть неудачу, когда это очень специфический тип данных, но я не могу найти доказательств нигде по этой проблеме.
Dan McKinnon 05 дек. 2010, в 03:19
0

Кроме того, я первоначально видел эту проблему, когда тип данных был просто INTEGER, но это также позволяет более 16777216 записей. Обратите внимание, что до того, как это было установлено в качестве первичного ключа, записи, в которые БЫЛО поступать, просто дупс начали появляться в случайное время после того, как он получил прошлый идентификатор записи 16777216. Это звучит как ошибка, но я не могу найти никаких доказательств этого ошибка появляется где угодно. Если бы это была какая-то известная ошибка, это было бы полезно.
Dan McKinnon 05 дек. 2010, в 03:21

Показать ещё 2 комментария

Теги:

mysql

sql

mysql-error-1062

2 ответа

Ещё вопросы

16777216 - максимальное количество значений в 24-битном целом числе. Каков размер значения, которое вы используете в столбцах PRIMARY и UNIQUE?
поле первичного ключа является первичным ключом BIGINT, а не нулевым автоприращением без знака.
я нахожу это невероятным совпадением, что 16777216 будет записью, которая продолжает терпеть неудачу, когда это очень специфический тип данных, но я не могу найти доказательств нигде по этой проблеме.
Кроме того, я первоначально видел эту проблему, когда тип данных был просто INTEGER, но это также позволяет более 16777216 записей. Обратите внимание, что до того, как это было установлено в качестве первичного ключа, записи, в которые БЫЛО поступать, просто дупс начали появляться в случайное время после того, как он получил прошлый идентификатор записи 16777216. Это звучит как ошибка, но я не могу найти никаких доказательств этого ошибка появляется где угодно. Если бы это была какая-то известная ошибка, это было бы полезно.

Jon Black · Answer 1 · 2010-12-05T03-00-00.000Z

просто любопытно...

какая-либо особая причина, по которой вы не используете infid данных загрузки для заполнения ваших таблиц?

если вам нужно обработать данные в своем приложении перед загрузкой, вы все равно можете это сделать, а вывести файл csv вместо вызова sproc 100 миллионов раз. load data infile будет намного быстрее!

см. здесь - http://dev.mysql.com/doc/refman/5.1/en/load-data.html

Вам действительно нужен первичный ключ без знака bigint (8 байт) против целого числа без знака (4 байта) с максимальным значением 4294967295 (4 миллиарда)

см. здесь - http://dev.mysql.com/doc/refman/5.0/en/numeric-types.html

просто мысли...

если я делаю нагрузку infile, как это будет сравниваться, когда нагрузка снова и снова переходит от вставок базы данных к вводу / выводу записи и чтения созданного CSV? Я предложил это же действие другому разработчику, и он сказал, что изначально было много проблем с производительностью со стороны ввода / вывода ... спасибо!
Создание CSV-файла с 100 миллионами строк ++ не займет много времени, но вы можете разбить его на 10 файлов, скажем, по 10 миллионов строк, а затем использовать файл данных загрузки для загрузки каждого из них по отдельности. Я полагаю, что ваш текущий метод загрузки занимает несколько часов, если не больше. Используя ваше приложение для генерации 1 или более файлов .csv, а затем для массовой загрузки, все будет сделано за 20 минут. Несколько полезных советов здесь pastie.org/1348793 - надеюсь, это поможет.
Текущий метод занимает абсолютно вечно. я обязательно посмотрю, чтобы сделать это изменение, спасибо!
у меня CSV работает из командной строки mysql, но я не могу понять, как правильно вызвать это в коде .NET. Любая помощь приветствуется, благодаря вызову ExecuteNonQuery для полного сценария просто ошибки
изменив \\ символы на // сделал свое дело

Ken Bloom · Answer 2 · 2010-12-05T01-21-00.000Z

0

Вы уверены, что в нем нет MEDIUMINT? Запустите show create table в таблице, которая показывает эту проблему.

Ken Bloom 05 дек. 2010, в 01:21

0

Вот результаты этого разделения на 2 комментария:
Dan McKinnon 05 дек. 2010, в 03:59
0

метрики | metrics CREATE TABLE ( classification int (11) по умолчанию NULL, edit_distance int (11) по умолчанию NULL, edit_goodness float по умолчанию NULL, shorter_name_len int (11) по умолчанию NULL, spatial_distance float (30,2) по умолчанию NULL, spatial_precision_deg float (30,5) по умолчанию NULL , spatial_goodness float (30,5) по умолчанию NULL,
Dan McKinnon 05 дек. 2010, в 03:59
0

feature_type_distance двойной NULL по умолчанию, score поплавок (30,3) NOT NULL, metrics_id BIGINT (20) без знака NOT NULL AUTO_INCREMENT, ch_unique_feature_id INT (11) по умолчанию NULL, ch_unique_name_id INT (11) по умолчанию NULL, ref_unique_feature_id INT (11) по умолчанию NULL, ref_unique_name_id int (11) по умолчанию NULL, set_id int (11) по умолчанию NULL, PRIMARY KEY ( metrics_id )) ENGINE = InnoDB AUTO_INCREMENT = 16777217 DEFAULT CHARSET = latin1 | + --------- + --------------------------------------- -----------------
Dan McKinnon 05 дек. 2010, в 03:59
0

@ Дэн: я не вижу здесь ничего проблемного. Возможно, что-то не так в коде C #, который питает базу данных.
Ken Bloom 05 дек. 2010, в 04:06
0

C # call: sqrstart = "call inmetrics ("; sqrest = "? Классификация,? EditDistance,? EditGoodness,? ShorterNameLen,? SpatialDistance,"; sqrest1 = "? SpatialPrecisionDeg,? SpatialGoodness,? FeatureTypeDistance,? MetricsID,"; sqrest2 = = "? ChUniqueFeatureID,? ChUniqueNameID,? RefUniqueFeatureID,? RefUniqueNameID,? SetID)";
Dan McKinnon 05 дек. 2010, в 04:08
0

SqlDbHelper.ExecuteNonQuery (sqrstart + sqrest + sqrest1 + sqrest2, paramClassification, paramEditDistance, paramEditGoodness, paramShorterNameLen, paramSpatialDistance, paramSpatialPrecisionDeg, paramSpatialGoodness, paramFeatureTypeDistance, paramMetricsID, paramChUniqueFeatureID, paramChUniqueNameID, paramRefUniqueFeatureID, paramRefUniqueNameID, paramSetID);
Dan McKinnon 05 дек. 2010, в 04:10
0

хранимая процедура: CREATE DEFINER = featurematch @ % PROCEDURE inmetrics (в целом vclassification, в целом veditdistance, в float veditgoodness, в целом vshorternmaelen, в float vsdaldistance, в float vspatialprecisiondeg, в float vgidity inmetring, в значении целое число, десятичное число chuniquenameid, целое число vrefuniquefeatureid, десятичное число refuniquenameid, целое число vsetid)
Dan McKinnon 05 дек. 2010, в 04:11
0

НАЧАТЬ вставку в метрики (классификация, edit_distance, edit_goodness, shorter_name_len, пространственная_distance, пространственная_precision_deg, пространственная_goodness, feature_type_distance, metrics_id, ch_unique_feature_id, ch_unique_name_id, ref_unique_feature_id, ref_unique_id_id)
Dan McKinnon 05 дек. 2010, в 04:11
0

значения (классификация, veditdistance, veditgoodness, vshorternmaelen, vspatialdistance, vspatialprecisiondeg, vspatialgoodness, vfeaturetypedistance, vmetricsid, vchnuniquefeatureid, chuniquenameid, vrefuniquefeatureid; refuniquenameid, vsetitid) КОНЕЦ
Dan McKinnon 05 дек. 2010, в 04:13
0

есть весь соответствующий код. сообщение - это просто трассировка стека, где выполняется этот вызов хранимой процедуры. это определенно не сторона C #, где дела идут плохо.
Dan McKinnon 05 дек. 2010, в 04:14
0

@ Дэн: Эти вещи слишком сложны, чтобы читать их как комментарии к моему ответу. Не могли бы вы потратить время на то, чтобы отредактировать свой вопрос, чтобы в удобной для вас форме обработать всю необходимую информацию, чтобы мы могли вам в этом помочь. catb.org/~esr/faqs/smart-questions.html
Ken Bloom 05 дек. 2010, в 04:15
0

@Dan: Откуда вы знаете, что C # не запрашивает базу данных для вставки двух значений с одним и тем же первичным ключом 16777216 (либо потому, что вы это явно просили, либо из-за какого-то целочисленного переполнения, к которому вы не обращали внимания .) И без тела хранимой процедуры мы не можем знать, происходит ли какое-либо случайное преобразование в MEDIUMINT происходящее в теле хранимой процедуры.
Ken Bloom 05 дек. 2010, в 04:17
0

AUTO_INCREMENT для metrics_id , по-видимому, не используется, так как вы все равно vmetricsid значение как vmetricsid в хранимой процедуре.
Ken Bloom 05 дек. 2010, в 04:20
0

О боже, я не могу поверить, что это может быть что-то такое простое / глупое. это правильно, если взглянуть свежим взглядом на то, на что один человек слишком долго смотрел. Я буду обновлять, если это работает ...
Dan McKinnon 05 дек. 2010, в 04:24
0

просто для дальнейшего использования - просто вставьте весь свой код сюда pastie.org
Jon Black 05 дек. 2010, в 04:45
0

как это помогает с ограничениями комментариев в символах? Спасибо
Dan McKinnon 05 дек. 2010, в 06:51

Показать ещё 14 комментариев