[Голышев Михаил]

Цитата:

Сообщение от smoyk

Разве не так?

Это верно только для нативной базы.
Для SQL это не верно.

MS SQL Server самостоятельно выбирает ключи поиска и план выполнения запроса. Независимо от переданного ему ключа через функцию SETCURRENTKEY

пример:

recCustLedgerEntry	Record	Cust. Ledger Entry	
________________________________________
recCustLedgerEntry.RESET;
recCustLedgerEntry.SETCURRENTKEY("Customer No.","Posting Date","Currency Code");
recCustLedgerEntry.SETRANGE("Customer No.",'C3438');
recCustLedgerEntry.SETRANGE("Posting Date",231106D);
recCustLedgerEntry.SETRANGE("External Document No.",'03');
recCustLedgerEntry.FIND('-');

Этот код приведет к выполнению следующего SQL запроса:

SELECT  * FROM "dbo"."КРОК$Cust__Ledger_Entry" 
WHERE (("External_Document_No_"='03')) 
  AND (("Customer_No_"='C3438')) 
  AND (("Posting_Date"='2006-11-23')) 
ORDER BY "Customer_No_","Posting_Date","Currency_Code","Entry_No_"

Данный запрос будет выполнен по следующей схеме:

Параметры, переданные через SETCURRENTKEY, трактуется исключительно как порядок сортировки полученного результата (поле ORDER BY) и никак не влияют на выбор ключей, используемых при поиске.

Изменим вышеприведенный код, убрав из него вызов SETCURRENTKEY:

recCustLedgerEntry	Record	Cust. Ledger Entry	
________________________________________
recCustLedgerEntry.RESET;
recCustLedgerEntry.SETRANGE("External Document No.",'SCI_604983/SZ622586');
recCustLedgerEntry.SETRANGE("Posting Date",200906D);
recCustLedgerEntry.SETRANGE("Customer No.",'C3137');
recCustLedgerEntry.FIND('-');

Этот код приведет к выполнению SQL запроса:

SELECT  * FROM "dbo"."КРОК$Cust__Ledger_Entry" 
WHERE (("External_Document_No_"='03')) 
  AND (("Customer_No_"='C3438')) 
  AND (("Posting_Date"='2006-11-23')) 
ORDER BY "Entry_No_"

Сортировка в данном случае будет произведена по умолчанию, то есть по первичному ключу «Entry No.».

План выполнения запроса выглядит следующим образом:

Данный план выполнения лучше предыдущего, поскольку в нем отсутствует трудоемкая задача – сортировка конечного результата (сортировка входит в этап join’а таблиц).

Последний запрос в среднем в 5-10 раз быстрее первого (зависит от размеров таблицы)