Производительность формы при добавлении Outer Join DataSource

Question

У меня есть пользовательская форма со следующей настройкой Datasource;

SalesTable 
SalesLine (SalesTable - Inner Join) 
InventTable (SalesLine - Inner Join) 
InventDim (SalesLine - Inner Join) 

... который работает без каких-либо проблем с производительностью.

Когда я добавляю следующее;

InventHazardousGroup (InventTable - Outer Join) 

... Я не вижу никаких проблем с производительностью в среде разработки, однако в производственной среде запрос ужасно медленно, что означает, что форма занимает много времени для загрузки.

Журнал трассировки SQL Statement выдал следующий результат в обеих средах;

(Я закончил список полей с и так далее, потому что он длинный);

SELECT A.SALESID,A.SALESNAME,A.RESERVATION,A.CUSTACCOUNT,A.INVOICEACCOUNT,A.DELIVERYDATE,A.DELIVERYADDRESS,A.URL,A.PURCHORDERFORMNUM,A.SALESTAKER,A.SALESGROUP,A.FREIGHTSLIPTYPE,A.DOCUMENTSTATUS,A.INTERCOMPANYORIGINALSALESID,etc 
FROM {OJ INVENTTABLE C LEFT OUTER JOIN INVENTHAZARDOUSGROUP E ON ((E.DATAAREAID=?) 
AND (C.HAZARDOUSGROUPID=E.HAZARDOUSGROUPID))},SALESTABLE A,SALESLINE B,INVENTDIM D 
WHERE ((A.DATAAREAID=?) 
AND (A.SALESTYPE=?)) 
AND ((B.DATAAREAID=?) 
AND (A.SALESID=B.SALESID)) 
AND ((C.DATAAREAID=?) 
AND (B.ITEMID=C.ITEMID)) 
AND ((D.DATAAREAID=?) 
AND (B.INVENTDIMID=D.INVENTDIMID)) 
ORDER BY A.DATAAREAID,A.SALESID OPTION(FAST 1) 

Есть ли причина, почему это должно быть настолько медленным в одной среде, но не в другом? Данные, которые я тестировал в среде разработки, довольно недавно, около 1 месяца. У меня такая же проблема с производительностью в производственной среде, в другой компании.

Answer 1

У меня возникла эта проблема, и я не думаю, что она имеет какое-либо отношение к внешнему соединению. Скорее всего, это связано с тем, что количество запросов, создаваемых формой в процессе производства или разработки. SQL пытается кэшировать запрос, когда он используется, и AX любит передавать объекты в SQL как переменные. Скорее всего, у вас есть плохой план кеша в Production, который затем используется всеми пользователями. Я предлагаю использовать Force Literals. Я использовал его редко в нескольких местах, и это оказало большое влияние на производительность.

Answer 2

Проверьте план выполнения запроса.

Самый простой способ войти в infolog (установка длинных запросов на вкладке SQL в пользовательских настройках), затем дважды щелкнуть запрос о нарушении.

В противном случае попробуйте перестроить индекс таблиц и таблицы create statistics.

Answer 3

Проверка индексов в AX существует в SQL Server.

Answer 4

Какую версию SQL-сервера вы используете в своей разработке и какую версию в процессе производства. Сделайте DBCC TRACESTATUS(-1);, чтобы определить, какие флажки установлены в dev vs prod. Убедитесь, что они не отличаются. Я видел проблемы, когда, когда они это делают, проблема производительности возникает в одном, но не в другом.

Выполняет ли запрос ВСЕГДА медленное производство, или это только НЕКОТОРЫЕ работают медленно?