Есть БД Firebird, в таблице заказов сотни тысяц записей, нужно отбирать оттуда данные за период и грузить в 1С. Метод Open() отрабатывает быстро, а вот при первом обращении к EOF() начинается полный тупняк, ждёт где-то полчаса, пока не начнётся перебор записей. Можно ли как-то ускорить работу?



Процедура КнопкаВыполнитьНажатие(Кнопка)
    Conn = Новый COMОбъект ("ADODB.Connection");
    Conn.Open("Provider=SQLOLEDB.1;Integrated Security=SSPI;Persist Security Info=False;Initial Catalog=Northwind");
    
    RS = Новый COMОбъект ("ADODB.RecordSet");
    RS.Open("select * from orders where orders.sdate + orders.sdate >= cast('2018-08-30 15:00:00' as timestamp)", Conn);
    
    Пока НЕ (RS.EOF) Цикл            // <==== при первом обращении к EOF() очень долго думает, дальше перебор идет нормально
        Сообщить(RS.Fields(1).Value());
        RS.MoveNext();
    КонецЦикла;

    RS.Close();
КонецПроцедуры

"orders.sdate + orders.sdate >= cast('2018-08-30 15:00:00' as timestamp)"

Не делай так.

(0) ну наверное индексов нету соответствующих и много записей отбираете сразу

а вообще, ступай на форум Firebird

может поможет
http://www.ibase.ru/45-ways-to-improve-firebird-performance-russian

что сие условие значит?

orders.sdate + orders.sdate >= cast('2018-08-30 15:00:00' as timestamp)

Замени Select * на список нужных тебе полей, исключи из выборки всякие блобы.

+(5)
в продакшене "*" испоьзовать - моветон.
https://forum.infostart.ru/forum9/topic53575/

(0) Плохо знаю восьмерку, но может есть возможность по-другому организвать выборку данных:

1) Делаем 2 запроса: один - на выборку строк, второй - только считающий количество записей с таким же фильтром за период, как первый

2) Цикл по первому рекордсету не через сравнение с EOF, а тупо по счетчику, пока не будет перебрано количество записей, вычисленное вторым запросом.

Таким образом, исключится проверка на EOF, вызывающая большую задержку.

(1) А как будет правильнее сделать? Там просто в одном поле дата, в другом время хранится

(6) (7) Там в реальности поля стоят, я просто поставил звёздочку, чтобы проще для понимания было.


Пока спасибо всем, натолкнули на мысли, буду пробовать.

(9) (1) А как будет правильнее сделать?

Если это поле orders.sdate индексировано, то твоя формула выключит индекс.
Отбери просто на началодня (или на конец) и отсеки лишнее в постобработке.

Если поле orders.sdate не индексировано - то его надо индексировать.

(0) Сообщить выкинь, тут на 90% Сообщить время жрет.

orders.sdate + orders.sdate>=
Однозначное не использование индекса же.

(13) см (1), (10)

(0) Вот еще можно поиграться с курсорами, но там по дефолту должны стоять оптимальные значения, нуавдруг
http://www.askit.ru/custom/vba_office/m9/09_05_02_recordset_opening.htm

Вот тут с числовыми значениями констант
http://www.askit.ru/custom/progr_admin/m13/13_03_02_ado_recordset_parameters.htm

А почему в условии одинаковые имена полей, если "в одном поле дата, в другом время хранится"?

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

(0) Используй PLAN в запросе чтобы явно указать используемый индекс.

(8) Задержку вызывает исполнение запроса, а не проверка на EOF.

(20) Цитата из (0):

Метод Open([текст запроса]) отрабатывает быстро, а вот _п_р_и_ _п_е_р_в_о_м_ _о_б_р_а_щ_е_н_и_и_ к EOF() ... ждёт где-то полчаса, пока не начнётся перебор записей

(21) При первом обращении к результату запроса и происходит выполнение запроса. Зачем его выполнять, если еще неизвестно, будет использован результат или нет?

(17) сори, там sdata + stime, это я автоматом лажанул, когда сюда вписывал

(11) (13) (15) (16) (19) таки да, спасибо за информацию, тоже как раз в этом направлении начал копать )

(23) Попробуй поставить 2 условия: одно чисто по дате, второе уже по дате + времени и принудительно использовать индекс, где есть поле даты. Тогда высоки шансы, что оптимизатор сначала отберет документы по индексу, а затем уже отбросит те, которые с начала дня не нужны.

Зачем складывать два одинаковых поля????

Наверное,там было stime?

Firebird выполняет запрос при первом обращении к результату.

при подсчете количества он делант полное сканирование,т.к.могут существовать несколько версий одной записи и для низкого уровня,это разные строки.

если долго,то сделайте ему collect garbage,станет быстро.

Ещё вопрос по поводу метода Open():

  > RS.Open(ТекстЗапроса, Conn);
  > RS.Open(ТекстЗапроса, Conn, 3);

Заметил, что если параметр не задавать (по умолчанию 0), то выборка происходит при первом обращении к EOF(), а если поставить 3, выборка просиходит при самом Open(). На что на самом деле влияет этот параметр при выборке?

(28) на то, какой курсор будет создаваться

Существует четыре курсор другого типа, определенные в ADO:
Динамический курсор дает возможность просмотра, добавления, изменения и удаления другими пользователями; разрешает все типы перемещения через записей , не зависит от закладки; и позволяет закладки, если поставщик поддерживает их.
Курсор набора ключей добавьте Behaves как динамический курсор, за исключением того, что он не позволяет просматривать записи другие пользователи и предотвращает доступ к записям, которые другие пользователи удаляют. Данные изменения другими пользователями по-прежнему будут отображаться. Здесь всегда поддерживает закладки и поэтому все типы перемещения по записей.
Статический курсор предоставляет статическую копию набора записей можно использовать для поиска данных или создавать отчеты; всегда позволяет закладки, а поэтому все типы перемещения через записей. Дополнения, изменения или удаления других пользователей будет недоступен. Это единственный тип курсора, допускается при открытии на стороне клиента записей объекта.
Однонаправленный курсор позволяет только просмотреть записей. Дополнения, изменения или удаления других пользователей будет недоступен. Это улучшает производительность в ситуациях, когда необходимо сделать только один проход по записей.

+(24) Еще вариант выбрать 2 таблицы и объединить их. Одна с датой >= 2018-08-31, а вторую - с датой = 2018-03-30 и время >= 15:00:00. В таком случае даже распараллелить исполнение запроса несложно.

(25) (27) все верно, это я когда сюда писал ошибся (23)

(29) т.е. 0 для простой выборки и дного прохода записей будет оптимально?

(30) как раз этим путем пробую идти: либо так, либо отбирать с точностью до дня, а в постобработке отсекать ненужные записи

(32) Отбирай в sql запросе ТОЛЬКО  по условию дата=день
по времени отсекай записи на клиенте.

Если еще сможешь понять досконально сам почему как в 0 имееет место быть,
то ты уже на другом уровне по sql