Вход | Регистрация
 
1С:Предприятие :: 1С:Предприятие 8 общая

Разница во времени выполнения запроса.

Разница во времени выполнения запроса.
Я
   ам794123
 
29.07.20 - 12:59
Есть примерно такой запрос:

ВЫБРАТЬ
    ВложенныйЗапрос.Период КАК Период,
    ВложенныйЗапрос.Регистратор КАК Регистратор,
    ВложенныйЗапрос.Организация КАК Организация,
...

который примерно за 1.5 сек выдает результа в 50 тыс. строк

Если этот запрос изменить на

ВЫБРАТЬ ПЕРВЫЕ 1000000
    ВложенныйЗапрос.Период КАК Период,
    ВложенныйЗапрос.Регистратор КАК Регистратор,
    ВложенныйЗапрос.Организация КАК Организация,
...

то те же 50 тыс. строк получаются за 0.7 сек то есть в два раза быстрее

Как это можно объяснить?

ПС. Сами запросы и измерения выполнялись в некой консоли запросов.
   Йохохо
 
1 - 29.07.20 - 13:07
1. недокешировал
2. оптимизатор плана прогоняет лимит на вложенный и выборка в нем меньше
3. лимит добавляет ордер бай в 1с автоматом и там что то оптимизируется
   spiller26
 
2 - 29.07.20 - 14:05
(0) Много факторов, оптимизация запроса в БД после первого обращения, загруженность БД и т.д.
Так что "Продолжайте наблюдения".
   ам794123
 
3 - 29.07.20 - 14:12
(1) (2) #ПродолжаюНаблюдения: первый пункт отпадает.
Если лимит увеличить до 100 млн. то время выполнения 1.2 сек в среднем. т.е. увеличилось, но не до предела.
выборка во вложенном запросе 90 тыс. строк, поэтому и второй пункт не проходит.
  Остается только внутренняя оптимизация 1с.

Я к чему - может стоит в целях оптимизации ставить заведомо большой лимит выборки в запросах? Или тут могут быть подводные камни.
   Ёпрст
 
4 - 29.07.20 - 14:57
(3) нет..это полная хрень.
Очисти все кеши, обнови статистику и запускай наеборот запросы. Будешь приятно удивлен
Или хотя бы замеры делай каждый раз после удаления кешей и обновления статистики.
   Ёпрст
 
5 - 29.07.20 - 14:58
А так, смотри реальный план выполнения запросо.. там почти есть все ответы
   LoneWanderer
 
6 - 29.07.20 - 15:01
(0)
Какая СУБД?
(правда, ответа на вопрос у меня всё равно нет, но вдруг станет скучно - пойду сам попробую)

Поверхностно - в oracle, например, можно написать хинт FIRST_ROWS - и при этом план построится сильно по другому.
MsSql, наверное, может вместо хинта использовать просто TOP.
   Ёпрст
 
7 - 29.07.20 - 15:06
(6) ага.. ща выеснится, что это файловая
   ам794123
 
8 - 29.07.20 - 15:10
(4) Не-е, чистить кеши, обновлять статистику это лабораторные опыты. На практике в реальной эксплуатации этого сделать невозможно. Запрос-то будет использоваться в реальной обработке, которую будут запускать обычные пользователи. Операнд ПЕРВЫЕ 1000000 уменьшит время выполнения у них или нет. Вот в чем вопрос.
   LoneWanderer
 
9 - 29.07.20 - 15:10
(7) Вполне может быть.
Там иногда запросы с GROUP BY (и без агрегатных функций) выполняются (в несколько раз) быстрее чем такие же с DISTINCT.
Хотя вроде это одно и тоже должно быть.
   ам794123
 
10 - 29.07.20 - 15:45
Усложнил запрос согласно бизнес-логики соединениями с дополнительными таблицам, индексами, связями и #ПродолжаюНаблюдения:
БАза серверная. на сервере только тестовые базы для отладки. Результирующая таблица во всех случаях одинаковая.

Лимит   59 999 Время 1,3 сек
Лимит   99 999 Время 1,4 сек
Лимит  999 999 Время 4,9 сек
Лимит  9999 999 Время 6,2 сек
Лимит 99999 999 Время 76,2 сек!
Безлимит - Время 1,3 сек!!  Ничего не понимяю(с)
 
Но на всякий случай решил использовать безлимит.
   hhhh
 
11 - 29.07.20 - 15:51
(10) в реальной практике запрос выполняется первый раз 5 секунд, второй раз 0.5 секунд. Потому что после 1-го раза закешировалось. Поэтому чтобы получить реальный результат, а не фуфло, как у тебя, нужно так: выполнил запрос, чистишь кеш, перезагружаешь сервер, выполняешь второй запрос. Тогда получишь реальные цифры.
   Жан Пердежон
 
12 - 29.07.20 - 15:53
(10) тебе толковые люди говорят: смотри план запроса, а ты продолжаешь гадать
   acht
 
13 - 29.07.20 - 15:56
(8) > уменьшит время выполнения у них или нет. Вот в чем вопрос.
А хрена ты его задаешь нам, а не реальным пользователям?
   Fragster
 
14 - 29.07.20 - 16:06
(10) на первые ххх опирается оптимизатор при выборе плана.
   Fragster
 
15 - 29.07.20 - 16:06
если на результат не влияет, то лучше не надо, надо данные держать в кэше и статистику актуальной.
   Fragster
 
16 - 29.07.20 - 16:07
чтобы данные лежали в кэше, надо, чтобы у скуля хватало памяти. там даже в винде есть счетчик специальный, считает промахи кэша скуля

Список тем форума
Рекламное место пустует  Рекламное место пустует
ВНИМАНИЕ! Если вы потеряли окно ввода сообщения, нажмите Ctrl-F5 или Ctrl-R или кнопку "Обновить" в браузере.