Providex Query Performance

Question

Я выполняю запрос к базе данных Providex, которую мы используем в MAS 90. Запрос состоит из трех таблиц, объединенных вместе, и он был медленным, но не невыносимым, занимая около 8 минут на цикл. Запрос содержит достаточное количество условий в предложении where:

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

Но таблицы и предложения where в 8-минутной версии времени выполнения:

(Первый параметр - это нижняя граница выбранного пользователем диапазона дат, второй - верхняя граница.)

FROM  "AR_InvoiceHistoryDetail" "AR_InvoiceHistoryDetail", 
"AR_InvoiceHistoryHeader" "AR_InvoiceHistoryHeader", "IM1_InventoryMasterfile" 
"IM1_InventoryMasterfile" 
WHERE "AR_InvoiceHistoryDetail"."InvoiceNo" = "AR_InvoiceHistoryHeader"."InvoiceNo" 
AND "AR_InvoiceHistoryDetail"."ItemCode" = "IM1_InventoryMasterfile"."ItemNumber" 
AND "AR_InvoiceHistoryHeader"."SalespersonNo" = 'SMC' 
AND "AR_InvoiceHistoryHeader"."OrderDate" >= @p_dr 
AND "AR_InvoiceHistoryHeader"."OrderDate" <= @p_d2

Однако оказывается, что другое поле даты в той же таблице должно быть тем, с которым сравнивается диапазон дат. Поэтому я изменил Даты заказа в конце предложения WHERE на InvoiceDate. У меня еще не было успешного выполнения запроса. И я ждал более 40 минут. Я не контролирую индексирование, потому что это база данных MAS 90, и я не верю, что могу напрямую изменить характеристики базы данных.

Что может вызвать такую ​​большую (как минимум, в 5 раз) разницу в производительности. Возможно, что OrderDate мог быть проиндексирован, а InvoiceDate - нет? Я пробовал между предложениями, но это не работает на диалекте Providex. Я использую интерфейс ODBC через .NET в моем механизме пользовательских отчетов. Я отлаживал отчет, и он запускался в точке выполнения базы данных, когда я попросил VS разорвать все, в том же месте, где ожидал 8-минутный отчет, так что это почти наверняка либо что-то в моем запросе, либо что-то в базе данных. что облажался.

Если только InvoiceDates не проиндексированы, что еще я могу сделать в диалекте ProvideX SQL, чтобы оптимизировать производительность этих запросов? Должен ли я изменить порядок моих критериев? Этот отчет получает результаты для конкретного продавца, поэтому существует условие SMC. Предыдущие предложения предназначены для внутренних объединений, а последнее предложение - для диапазона дат.

Я использовал одинаковый диапазон дат в версиях OrderDate и InvoiceDate, выполнил их все несколько раз и получил одинаковые результаты.

Answer 1

Я до сих пор точно не знаю, почему это так медленно, но у нас была другая проблема с результатами, полученными из запроса (мы переключились на использование OrderDate). Мы не получили некоторые результаты из-за характера таблицы IM1.

Поэтому я добавил Left Outer Join, как только выяснил синтаксис Providex для этого. И по какой-то причине, хотя у нас все еще есть 3 таблицы, теперь они работают намного быстрее.

Новые критерии запроса:

FROM  "AR_InvoiceHistoryHeader" "AR_InvoiceHistoryHeader", 
{OJ "AR_InvoiceHistoryDetail" "AR_InvoiceHistoryDetail" 
LEFT OUTER JOIN "IM1_InventoryMasterfile" "IM1_InventoryMasterfile"
ON "AR_InvoiceHistoryDetail"."ItemCode" = 
"IM1_InventoryMasterfile"."ItemNumber" }
WHERE "AR_InvoiceHistoryDetail"."InvoiceNo" = 
"AR_InvoiceHistoryHeader"."InvoiceNo" AND 
"AR_InvoiceHistoryHeader"."SalespersonNo" = 'SMC' 
AND "AR_InvoiceHistoryHeader"."InvoiceDate" >= ? 
AND "AR_InvoiceHistoryHeader"."InvoiceDate" <= ?

Странно, но, по крайней мере, я узнал больше о мире Providex Sql в процессе.

Answer 2

Я не использовал .NET, так что мой вопрос может показывать невежество, но в Access вы должны использовать SQL Pass-Through, чтобы получить результаты из ProvideX, если задействовано более одной таблицы.

Answer 3

Я никогда раньше не использовал ProvideX.

Поиском был справочный материал о синтаксисе для создания индекса.

При просмотре вашего запроса, есть три таблицы и пять критериев. Два критерия являются «критериями объединения», а три критерия являются критериями фильтрации:

AND "AR_InvoiceHistoryHeader"."SalespersonNo" = 'SMC'
AND "AR_InvoiceHistoryHeader"."OrderDate" >= @p_dr
AND "AR_InvoiceHistoryHeader"."OrderDate" <= @p_d2

Я не знаю, насколько хорош SalespersonNo для ограничения возвращаемых результатов, но было бы неплохо добавить индекс для этого.