Цитата:
Сообщение от
fed
Единственная реальная проблема с временными таблицами tempDB(а на самом деле - это ОБЫЧНЫЕ таблицы, просто система их автоматически удаляет) - это возможность засорить sql statement cache. То есть - если у тебя в D365FO стоит такой вот примерно код:
for(i=0;i<10000;i++)
{
myFavoritetempDbTable myTable;
//do something with the table
}
то велика вероятность того, что система создаст 10000 одинаковых временных таблиц с разными именами, потом отправит 10000 разных запросов на вставку и выборку и тп. В результате кэш сиквела затрешиться.
Но от такого антипаттерна легко защититься, добавив еще одно поле для хранения i во временную таблицу, создать только один экземпляр этой временной таблицы и просто во все запросы добавить условие myTable.fieldI == i
А InMemory временные таблицы изначально были достаточно бесполезной штукой. Запросы с их участием обрабатывались на AOS (То есть - из запроса исключалась временная таблица, остатки запроса отправлялись на SQL, оттуда приходил результат - зачастую сотни мегабайт, результат записывался куда-то на AOSовский диск и потом это все медленно и печально джойнилось с inMemory table где-то на дисках AOS). Если просто быстродействия хочется (без необходимости джойнить временную таблицу куда-то), то лучше Map или там List использовать, потому что они в памяти остаются, а не высвопляются на диск AOS если в таблице больше нескольких сотен записей образовалось.
Вряд ли единственная. Вот тут упоминаются 4 базовые проблемы и 2 специфичные.
https://community.dynamics.com/ax/f/...-tempdb/898314
Assuming you don't have
basic configuration issues with your TempDB, i.e.
too small with not enough auto-expand, insufficient storage on the hosting volume, not enough files per the recommended configuration, sufficiently fast storage to handle you workload, etc., you could have one of two types of problems.
First, [упоминается проблема когда просто не влезает] но можно как-то увидеть.
Second, [упоминается проблема c версиями записей при долгом запросе] что нелегко идентифицировать.
Цитата:
Сообщение от
fed
Если просто быстродействия хочется (без необходимости джойнить временную таблицу куда-то), то лучше Map или там List использовать, потому что они в памяти остаются, а не высвопляются на диск AOS если в таблице больше нескольких сотен записей образовалось.
Именно. Программист может полагаться на сборщик мусора, не C++ в конце концов, но чтобы твой код полагался на то что на стороне SQL Server адекватное администрирование и ресурсы, это слишком оптимистично.
То есть при использовании TempDB мы отвечаем за наше некое решение, в котором полагаемся на то что вне нашего контроля. Возможно сказать что это не ответственность программиста раз штатное средство, но клиент нанимает опытных специалистов именно за их интуитивное избегание ненужных проблем.