Переключение на Главную Страницу Страницы: [1] 2  ОтправитьПечать
Очень популярная тема (более 25 ответов) оптимизация запроса для формы списка справочника с остатком (число прочтений - 6799 )
pavel_tr
Senior Member
****
Отсутствует



Сообщений: 279
Местоположение: Казань
Зарегистрирован: 14. Октября 2006
Пол: Мужской
оптимизация запроса для формы списка справочника с остатком
05. Октября 2016 :: 13:46
Печать  
Форма списка справочника "Товары" переписана на прямой запрос на табличном поле с поставщиком данных ODBC. В форме присутствует колонка с остатком по выбранному складу. Часть запроса выглядит так:

FROM $Справочник.Товары as Спр (nolock)
left join $РегистрОстатки.Остатки(
                                   ,
                                   ,
                             Склад = ?ТекущийСклад(14,9)
                                   ,
                             (Товар),(Остаток)
                                                           ) остаток on остаток.Товар = Спр.ID

После открытия периода в начале месяца форма списка "подвисает" при открытии и листании. Вместо моментального отображения информации, примерно минуту выполняется запрос для каждой порции данных. Ночью выполняется обновление статистики и форма снова летает. Всё бы ничего, но объёмы данных выросли и теперь такие зависания могут возникать и в течение дня. Начал разбираться в чём причина. Сделал копию базы, открыл период, статистику не обновлял. Смотрю план выполнения запросов.  С правильной статистикой поиск по кластерному индексу регистра остатков с таким seek predicates: Prefix: [book1_SQL].[dbo].[RG1501].PERIOD; [book1_SQL].[dbo].[RG1501].SP1511 = Scalar Operator('2016-10-01 00:00:00.000'); Scalar Operator([book1_SQL].[dbo].[SC10].[ID] as [Спр].[ID])
А с тухлой статистикой - так: Prefix: [book2].[dbo].[RG1501].PERIOD = Scalar Operator('2016-11-01 00:00:00.000')

Можно ли как-то повлиять на это кроме запуска обновления статистики по расписанию? Сейчас настроил обновление раз в два часа, но она выполняется минут 10 и нагрузку даёт нехилую - не выход это.
  
Наверх
 
IP записан
 
trad
1c++ power user
1c++ donor
1c++ moderator
Отсутствует



Сообщений: 3050
Местоположение: Киров
Зарегистрирован: 23. Мая 2006
Пол: Мужской
Re: оптимизация запроса для формы списка справочника с остатком
Ответ #1 - 05. Октября 2016 :: 14:22
Печать  
каким по порядку идет измерение Товар?
если не первым, то стоит ли галка отбор итогов?
  

1&&2&&3
Наверх
 
IP записан
 
pavel_tr
Senior Member
****
Отсутствует



Сообщений: 279
Местоположение: Казань
Зарегистрирован: 14. Октября 2006
Пол: Мужской
Re: оптимизация запроса для формы списка справочника с остатком
Ответ #2 - 05. Октября 2016 :: 16:24
Печать  
В том то и дело, что первым. У нас база самописная, могу ручками добавить индекс конечно, но может другой выход есть?
  
Наверх
 
IP записан
 
Djelf
God Member
*****
Отсутствует


Ubuntu + wine@etersoft
+ 1C 7.7

Сообщений: 634
Местоположение: Питер
Зарегистрирован: 02. Ноября 2007
Пол: Мужской
Re: оптимизация запроса для формы списка справочника с остатком
Ответ #3 - 05. Октября 2016 :: 17:50
Печать  
Лучше бы добавить... селективность по товару значительно выше, должно быть не просто быстрее, а очень очень быстрее.
С тухлой статистикой у тебя оптимизатор считает что ему без разницы есть склад или нет (потом типа отфильтрует) т.к. складов мало и он путается, а если будет индекс по товару, предполагаю, оптимизатор так не будет делать.
Как вариант использовать указание индекса WITH (INDEX (незнаюкаконутебятамзавется)) https://technet.microsoft.com/ru-ru/library/bb677261(v=sql.100).aspx
А зачем FROM $Справочник.Товары as Спр (nolock) left join $РегистрОстатки.Остатки( ?
В товарах обычно значительно быть больше позиций, чем есть на остатках.
Может стоит наоборот? Товары брать из регистра, и left join к ним товары, если требуется по их реквизитам дополнительный фильтр (это в том случае, если индекса в регистре по товару нет).
  
Наверх
www  
IP записан
 
pavel_tr
Senior Member
****
Отсутствует



Сообщений: 279
Местоположение: Казань
Зарегистрирован: 14. Октября 2006
Пол: Мужской
Re: оптимизация запроса для формы списка справочника с остатком
Ответ #4 - 06. Октября 2016 :: 03:45
Печать  
С тухлой статистикой и без индекс используется один и тот же, про хинт WITH знаю, но тут он, видимо, не поможет.
По порядку таблиц. Это запрос для формы списка справочника. Показывать нужно все элементы. А склад, теоретически, вообще может быть не выбран.
Попробую добавить доп.индекс.
  
Наверх
 
IP записан
 
trad
1c++ power user
1c++ donor
1c++ moderator
Отсутствует



Сообщений: 3050
Местоположение: Киров
Зарегистрирован: 23. Мая 2006
Пол: Мужской
Re: оптимизация запроса для формы списка справочника с остатком
Ответ #5 - 06. Октября 2016 :: 06:14
Печать  
доп индекс не поможет, т.к. уже есть необходимый для этой задачи
  

1&&2&&3
Наверх
 
IP записан
 
trad
1c++ power user
1c++ donor
1c++ moderator
Отсутствует



Сообщений: 3050
Местоположение: Киров
Зарегистрирован: 23. Мая 2006
Пол: Мужской
Re: оптимизация запроса для формы списка справочника с остатком
Ответ #6 - 06. Октября 2016 :: 06:25
Печать  
чему равна опция "max degree of parallelism" ?
  

1&&2&&3
Наверх
 
IP записан
 
pavel_tr
Senior Member
****
Отсутствует



Сообщений: 279
Местоположение: Казань
Зарегистрирован: 14. Октября 2006
Пол: Мужской
Re: оптимизация запроса для формы списка справочника с остатком
Ответ #7 - 06. Октября 2016 :: 07:05
Печать  
Да, доп. индекс не помог.
Max degree of parallelism сейчас стоит 0. На сервере 2 Xeon E5645 2,4 Ghz. Я ставил эксперименты, пробовал разные значения, с 0 в целом работает лучше. При попытке распараллеливать запросы какие-то тяжёлые отчёты работали шустрее, но многие жаловались что обычная работа по ощущениям стала менее комфортной и неспешной.
  
Наверх
 
IP записан
 
trad
1c++ power user
1c++ donor
1c++ moderator
Отсутствует



Сообщений: 3050
Местоположение: Киров
Зарегистрирован: 23. Мая 2006
Пол: Мужской
Re: оптимизация запроса для формы списка справочника с остатком
Ответ #8 - 06. Октября 2016 :: 07:12
Печать  
я использую 1
1с рекомендует 1
  

1&&2&&3
Наверх
 
IP записан
 
pavel_tr
Senior Member
****
Отсутствует



Сообщений: 279
Местоположение: Казань
Зарегистрирован: 14. Октября 2006
Пол: Мужской
Re: оптимизация запроса для формы списка справочника с остатком
Ответ #9 - 06. Октября 2016 :: 07:12
Печать  
Хорошо, попробую
  
Наверх
 
IP записан
 
trad
1c++ power user
1c++ donor
1c++ moderator
Отсутствует



Сообщений: 3050
Местоположение: Киров
Зарегистрирован: 23. Мая 2006
Пол: Мужской
Re: оптимизация запроса для формы списка справочника с остатком
Ответ #10 - 06. Октября 2016 :: 07:13
Печать  
интересно увидеть весь план "с тухлой статистикой"
  

1&&2&&3
Наверх
 
IP записан
 
trad
1c++ power user
1c++ donor
1c++ moderator
Отсутствует



Сообщений: 3050
Местоположение: Киров
Зарегистрирован: 23. Мая 2006
Пол: Мужской
Re: оптимизация запроса для формы списка справочника с остатком
Ответ #11 - 06. Октября 2016 :: 07:16
Печать  
и до кучи, статистику можно обновлять исключительно для одной таблицы или даже для одного индекса
  

1&&2&&3
Наверх
 
IP записан
 
pavel_tr
Senior Member
****
Отсутствует



Сообщений: 279
Местоположение: Казань
Зарегистрирован: 14. Октября 2006
Пол: Мужской
Re: оптимизация запроса для формы списка справочника с остатком
Ответ #12 - 06. Октября 2016 :: 07:56
Печать  
10 минут обновляется статистика по одной таблице остатков, я это и использую. Ночью статистика по всей базе обновляется за 3,5 часа.
rg1501.sqlplan
  
Наверх
 
IP записан
 
trad
1c++ power user
1c++ donor
1c++ moderator
Отсутствует



Сообщений: 3050
Местоположение: Киров
Зарегистрирован: 23. Мая 2006
Пол: Мужской
Re: оптимизация запроса для формы списка справочника с остатком
Ответ #13 - 06. Октября 2016 :: 09:27
Печать  
max degree of parallelism = 1
тоже скорее всего тут не поможет, так как, судя по плану, запрос и без этого в 1 поток выполняется
  

1&&2&&3
Наверх
 
IP записан
 
pavel_tr
Senior Member
****
Отсутствует



Сообщений: 279
Местоположение: Казань
Зарегистрирован: 14. Октября 2006
Пол: Мужской
Re: оптимизация запроса для формы списка справочника с остатком
Ответ #14 - 06. Октября 2016 :: 09:57
Печать  
Да, я это заметил. В копии базы, над которой ставил эксперименты, сейчас запрос снова выполняется быстро, хотя я ничего не делал. И план правильный. Видимо стоимость этой пары планов очень близка
  
Наверх
 
IP записан
 
Переключение на Главную Страницу Страницы: [1] 2 
ОтправитьПечать