Удаление / Обновление / Вставка данных в правильном порядке MSSQL -> MySQL

Question

Моя проблема в настоящее время выглядит следующим образом:

У меня есть стол A, который копирует элементы в таблицу переноса на основе того, произошла ли транзакция Обновление, Вставка или Удаление в таблице A т.е.

Таблица A -> новая вставка

Триггер активирует и вставляет строку в таблицу переноса с двумя другими столбцами - DateQueried а также QueryType (Куда DateQueried дата срабатывания триггера и QueryType это "Удалить", "Вставить" или "Обновить" в зависимости от типа триггера)

Однако теперь мне нужно перенести эти данные на веб-сервер по связанной таблице (все это нормально и делает как надо). В настоящее время у меня есть скрипт PowerShell для этого. Сценарий выполняет следующие действия:

• Выберите все значения из моей таблицы перевода, заказы по datequeried
• Запустите цикл foreach, который запускает хранимую процедуру для вставки / обновления / удаления этого значения на веб-сервере, в зависимости от значения QueryType,

Этот метод очень медленный, сценарий выполняется с 30-минутным таймером, и мы можем столкнуться с ситуацией, когда мы получаем более 100000 строк в течение этого 30-минутного периода времени, что означает 100000 подключений к БД через сценарий PowerShell (особенно при наличии 15 таблиц что нужно пройти через этот процесс).

Есть ли лучший способ получить эти значения, запустив внутреннее соединение? Ранее я просто запускал всю таблицу сразу через хранимую процедуру, которая удаляла бы все значения со второго сервера с QueryType удалить, затем запустить вставки, а затем обновления. Однако у этого были некоторые проблемы, если человек должен был создать новую работу, затем удалить работу, затем заново создать работу, затем обновить работу, а затем снова удалить работу. Моя хранимая процедура будет обрабатывать все удаления, ТОГДА все вставки, ТОГДА все обновления, поэтому, даже если строка была удалена, она пойдет и вставит ее снова.

Затем я перенастроил его еще раз и вместо этого передал только первичные ключи, и всякий раз, когда я запускал хранимую процедуру, она обрабатывает удаления на основе первичных ключей, затем для вставок и обновлений сначала присоединяется к исходной таблице первичных ключей (что, если был ранее удален, не даст результатов и, следовательно, не будет вставлен). Но я столкнулся с проблемой, когда запрос жевал слишком много ресурсов для процесса и время от времени бомбил сервер (ему приходилось пытаться объединить> 100000 результатов в таблицу, содержащую более 10 миллионов строк). Также была другая проблема, когда вставлялась строка с только нулевыми значениями для каждого столбца, где соединение не работало. Затем, когда это произойдет снова, возникнет ошибка первичного ключа, и хранимая процедура остановится.

Есть ли еще один вариант, который я упускаю из виду, который бы значительно ускорил процесс или я просто застрял с ограничениями на сервере, и, возможно, мне придется предположить, что компания обрабатывает загрузки только в конце каждого дня, а не через 30 минут? график они хотели бы?

Answer 1

Придерживайтесь массового удаления / вставки / обновления заказа.

Но:

• Вставляйте только те строки, в которых нет более позднего удаления (все изменения в любом случае будут потеряны).
• Обрабатывать только те обновления, в которых нет более поздних строк вставки или удаления (все изменения будут перезаписаны)