medoed,
Про логику синхронизации не пояснили, но судя по по приведённому Вами запросу с DELETE
в этой логике не всё оптимально. Т.е. по всей видимости сначала "набиваем под завязку" данными таблицу, а потом из таблицы "вычёркиваем" то, что не пригодилось.
Закономерно при таком подходе с ростом количества записей механизм будет проседать по производительности всё сильнее и сильнее, и замена GUID на любой другой идентификатор
только даст временную отсрочку.
Может быть есть возможность пересмотреть алгоритм синхронизации?
Скорее вы правы. План и то что в нём не нравится прилагаю.
Переписать есть возможность - а как бы вы сделали? Во время вставки в первую таблицу , триггер на ней прикрутить, который будет данные синхронизировать во второй? Но мне кажется это тоже не самый гут вариант.
я бы подумал насчет тригера но простого
вставлять ид-ки УДАЛЕННЫХ записей в ОТДЕЛЬНУЮ ТАБЛИЦУ
DEL_IDS - А ЕЕ уже юзать для удаления - она ж по идее будет небольшая - и удаление возможно будет быстрее
Если я правильно понял по I/U проблем нет - но в принципе если пишется
то можно lastupdate тоже по тригеру (I/U) писать (или вставлять в исх) - и выщемить Дельту по этой дате
ps Я видел подход с тригером для удаленных записей вообще универсальный
была одна таблица id , <table_name> и для каждой таблицы в OLTP был сделан тригер к-й писал
и эта таблица закачивалась и юзалась для удаления старых записей потом в DWH.
Имхо вполне рабочий и разумный подход.
