[fed]

Ладно - раз уж речь зашла о таблицах tempDB:
Как выяснилось, отключение функциональности Engineering Change в D365FO может очень прилично ускорить массовую вставку строк в складские журналы, заказы и sales quotation.
Есть такой метод: EngChgEcoResProductLifecycleStateRuleCheck::validateFilter(), который срабатывает при вставках в упомянутые выше таблицы. Этот метод копирует данные из таблицы в ее клон в tempDB и потом прогоняет запрос по этой временной копии. (можно у обычной, не временной таблицы вызвать метод vendTable.setTempDB() и система создаст tempDb-клон обычной таблицы) . Dispose() после этого не вызывается, соответственно на каждую вставку система генерирует уникальное новое имя временной таблицы, прогоняет по этой таблице запрос и тд. Если вставка идет в ручную (скажем - 300-400 строк заказов в час), то эти самые левые запросы в SQL Plan Cache погоды не делают. Если у нас имеется массовый импорт и мы пытаемся быстро залить скажем тысяч 20-30 строк, уникальные имена таблиц забивают Plan Cache, загоняя SQL Server на ёлку. (Кэш сбрасывается каждые 20-30 секунд и все запросы попадают на рекомпиляцию). Конечно скорость убивания SQL Server зависит от объема памяти на таковом и числа импортируемых строк, но вот например в моей VM, при ограничении размера памяти SQ Server в 8 Мб для того чтобы загнать сервер на ёлку достаточно было достаточно смешных 1500 строк в складских журналах...