SQL Server - экспорт большой таблицы без первичного ключа

Мне нужно синхронизировать большую таблицу ~ 500 миллионов строк без первичного ключа между SQL Server и MySQL. Таблица имеет только кластерный составной неуникальный индекс.

У меня есть ODBC-соединение между серверами, но импорт ~ 8 миллионов строк занял около 45 минут, поэтому я считаю, что больший одиночный импорт будет нецелесообразным, так как прерывания могут произойти в любой момент. Я не могу изменить существующую структуру таблицы, я могу добавить другие таблицы. После дальнейшего чтения смещение / выборка не подходит для больших таблиц. «Выбрать ... где х между ... и ...» не вариант, так как у меня нет уникального ключа.

Как я могу экспортировать таблицу в пакетах, которые гарантированно содержат все строки? Моя проблема заключается в том, что, поскольку кластеризованный ключ не является уникальным, упорядочение после него не гарантирует, что физические строки будут иметь одинаковый порядок между последовательными запросами, а упорядочение после того, как все столбцы займет слишком много времени. И как бы вы порекомендовали перенести пакеты через файлы ODBC или CSV?

sql-server

— никто
источник

Это будет повторение (обычная операция) или однократная операция?

— Богдан Богданов

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

— никто не

Я думаю, чтобы получить помощь по этому вопросу, вам нужно более подробно объяснить весь процесс (похоже, у вас очень сложная проблема)

— Богдан Богданов

Вы заметите, «поскольку кластеризованный ключ не является уникальным, упорядочение после него не будет гарантировать, что физические строки будут иметь одинаковый порядок между последовательными запросами». Поскольку порядок строк не сохраняется (если у вас нет данных о последовательности), вы не можете рассчитывать на получение того же физического порядка строк. Порядок строк не является по умолчанию ни порядком вставки, ни порядком индекса, но определяется предложением ORDER BY .

— RLF

Да, RLF, я согласен. Все столбцы целые, A, B, C, D, E. Кластерный ключ находится на ABC. Комбинация ABC не является уникальной, ни комбинация ABCD. Позволит ли "упорядочить по" неуникальному столбцу (столбцам) экспортировать всю таблицу в пакетном режиме? И Богдан Бодганов, платформа Stack, препятствует сложным проблемам, лучше просто решить вопрос. Как экспортировать всю большую таблицу как можно быстрее в пакетах без потери строк?

— никому

Предполагая, что у вас нет обновлений или удалений для исходной таблицы, вы можете попробовать следующее:
1. Сделайте копию существующей таблицы, используя синтаксис CTAS (для SQLServer это SELECT * into source_table_copy FROM source_table). Такая операция очень быстрая даже для огромных таблиц.
2. Добавьте after insertтриггер, source_tableкоторый копирует новую запись [ы] в source_table_copy.
3. Теперь, когда все новые записи source_tableпоступают source_table_copyтакже, и вы можете перемещать данные из скопированной таблицы в Mysql в пакетном режиме. Например, если у вас есть связь между двумя серверами, все может быть сделано в теле хранимой процедуры TSQL.
Например, фрагмент кода, который перемещает до 20 записей на новый сервер, может выглядеть так

 --declare table variable to keep deleted records until they delivered to target host 
  BEGIN TRANSACTION;
  DELETE TOP (20) FROM source_table_copy OUTPUT DELETED.* INTO @Table_Var;

  --insert data into linked server , or to csv file
  COMMIT;

Также можно использовать CURSOR для чтения данных, а затем удалить с where current ofпредложением.

** В идеале вам нужно запретить приложениям вставлять данные во source_tableвремя шага 1. Если это абсолютно невозможно, я воспользуюсь after insertтриггером, который добавляется непосредственно перед шагом 1 и удаляется сразу после его завершения, который копирует данные в какую-то другую таблицу, которую я могу позже сливаюсь с source_table_copy.

— a1ex07
источник

Спасибо за решение, я тоже что-то пробовал, правда с нормальной вставкой. Я попробую синтаксис CTAS, чтобы увидеть, не ускоряет ли это процесс. Дополнительный вопрос, если вы не возражаете: повлияет ли «триггер после вставки» на производительность?

— нет никого

Поскольку тело триггера очень простое (просто вставьте данные в другую таблицу), влияние на производительность будет минимальным.

— a1ex07