Таблица mysqldump без сброса первичного ключа

У меня есть одна таблица, распределенная на двух серверах с MySql 4. Мне нужно объединить их в один сервер для нашей тестовой среды.

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

Поскольку они находятся в рабочей среде, для меня невозможно каким-либо образом изменить их на существующих серверах.

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

Я пытался выяснить, как использовать команду mysqldump для игнорирования определенных полей, но ключи -disable просто изменяют таблицу, а не полностью избавляются от ключей.

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

Help!

Ответы

Ответ 1

если вам все равно, каково будет значение столбца auto_increment, а затем просто загрузите первый файл, переименуйте таблицу, затем заново создайте таблицу и загрузите второй файл. наконец, используйте

INSERT newly_created_table_name (all, columns, except, the, auto_increment, column)
       SELECT all, columns, except, the, auto_increment, column
         FROM renamed_table_name

Ответ 2

Чтобы решить эту проблему, я просмотрел этот вопрос, нашел ответ @pumpkinthehead и понял, что все, что нам нужно сделать, это найти + заменить первичный ключ в каждой строке на NULL, чтобы mysql использовал значение auto_increment по умолчанию вместо.

(your complete mysqldump command) | sed -e "s/([0-9]*,/(NULL,/gi" > my_dump_with_no_primary_keys.sql

Оригинальный вывод:

INSERT INTO `core_config_data` VALUES
    (2735,'default',0,'productupdates/configuration/sender_email_identity','general'),
    (2736,'default',0,'productupdates/configuration/unsubscribe','1'),

Преобразованный вывод:

INSERT INTO `core_config_data` VALUES
    (NULL,'default',0,'productupdates/configuration/sender_email_identity','general'),
    (NULL,'default',0,'productupdates/configuration/unsubscribe','1'),

Примечание: это все еще взломать; Например, он будет терпеть неудачу, если ваш столбец с автоматическим увеличением не является первым столбцом, но решает мою проблему в 99% случаев.

Ответ 3

Вы можете создать представление таблицы без столбца первичного ключа, а затем запустить mysqldump в этом представлении.

Итак, если в вашей таблице "пользователи" есть столбцы: id, name, email

> CREATE VIEW myView AS
  SELECT name, email FROM users

Изменить: а я вижу, я не уверен, есть ли другой способ.

Ответ 4

  • Clone Your table
  • Отбросить столбец в таблице клонирования
  • Дамп таблицы клонов без структуры (но с опцией -c для получения полных вставок)
  • Импорт, где вы хотите

Ответ 5

Это полная боль. Я обошел эту проблему, выполнив что-то вроде

sed -e "s/([0-9]*,/(/gi" export.sql > expor2.sql

на дампе, чтобы избавиться от первичных ключей, а затем

sed -e "s/VALUES/(col1,col2,...etc.) VALUES/gi" LinxImport2.sql > LinxImport3.sql

для всех столбцов, кроме первичного ключа. Конечно, вам нужно быть осторожным, чтобы ([0-9]*, не заменил ничего, что вы действительно хотите.

Надеюсь, что это поможет кому-то.

Ответ 6

SELECT null as fake_pk, `col_2`, `col_3`, `col_4` INTO OUTFILE 'your_file'
FIELDS TERMINATED BY ',' OPTIONALLY ENCLOSED BY '"'
LINES TERMINATED BY '\n'
FROM your_table;

LOAD DATA INFILE 'your_file' INTO TABLE your_table
FIELDS TERMINATED BY ',' OPTIONALLY ENCLOSED BY '"'
LINES TERMINATED BY '\n';

Для добавления привязанности вы можете установить триггер перед вставкой в ​​принимающую таблицу, которая устанавливает новый первичный ключ для строки достижений до начала вставки, тем самым используя регулярные дампы и все еще очищая ваш pk. Не тестировался, но чувствовал себя довольно уверенно в этом.

Ответ 7

Используйте фиктивный временный первичный ключ:

Используйте mysqldump обычно --opts -c. Например, ваш первичный ключ - "id". Отредактируйте выходные файлы и добавьте строку "dummy_id" в структуру вашей таблицы с тем же типом, что и "id" (но не первичный ключ, конечно). Затем измените оператор INSERT и замените 'id' на 'dummy_id'. После импорта удалите столбец "dummy_id".

Ответ 8

jimyi был на правильном пути.

Это одна из причин, по которым автоинкрементные ключи являются PITA. Одним из решений является не удаление данных, а добавление к ним.

CREATE VIEW myView AS
SELECT id*10+$x, name, email FROM users

(где $x - это одна цифра, однозначно идентифицирующая исходную базу данных), либо создание представления в исходной базе данных (которое вы намекаете, возможно, невозможно), либо использовать процедуру извлечения, подобную описанной автократией, или загрузить данные в стадию таблицы в тестовом окне.

В качестве альтернативы не создавайте таблицу в тестовой системе - вместо этого вставляйте отдельные таблицы для данных src, затем создавайте представление, которое извлекает из них оба:

CREATE VIEW users AS
(SELECT * FROM users_on_a) UNION (SELECT * FROM users_on_b)

С.

Ответ 9

Решение, которое я использовал, - это просто выполнить обычный экспорт данных экспортируемых мной данных, а затем удалить первичный ключ из операторов вставки с помощью редактора RegEx find & replace. Лично я использую Sublime Text, но я уверен, что TextMate, Notepad ++ и т.д. Могут сделать то же самое.

Затем я просто запускаю запрос, в котором когда-либо базы данных должны быть вставлены данные, скопировав их в окно запроса HeidiSQL или PHPMyAdmin. Если есть LOT данных, я сохраняю запрос вставки в файл SQL и вместо этого импортирую файл. Копирование и вставка с огромным количеством текста часто заставляет замораживать Chrome.

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

Ответ 10

Мне нравится временная таблица маршрутов.

create temporary table my_table_copy
select * from my_table;

alter table my_table_copy drop id;

// Use your favorite dumping method for the temporary table

Как и другие, это не универсальное решение (особенно учитывая OP миллионов строк), но даже при 10 ^ 6 строках для его запуска требуется несколько секунд, но он работает.