Проблема со скоростью выполнения запроса.
Стоит старая УПП1.3, платформа 8.2.15.294 и Microsoft SQL 2005
В какой то момент стал медленно выполняться отчет на СКД, когда установлен отбор по характеристике. На реальной базе вообще не выполняется. НО если настроить отбор через еще одну точку: вместо ВидПриемки = "Приемка1", установить ВидПриемки.Код = "1", то отчет работает также быстро как и раньше.
Полез смотреть в профайлер. Планы запросов разные и отличаются достаточно сильно. Ну это нормально. Но что вызвало у меня недопонимаение так это то, что для "быстрого" запроса Estimated SubStree Cost для последнего оператора показывает в 300 единиц в событии Showplan xml profile, а для "медленного" ESC = 12 единиц! Но уже в SQL:BatchCompleted "duration" у "быстрого" = 3000, у "медленного" = 300000.
Получается, что SQL Server предполагает, что один запрос будет быстрее другого в 25 раз, а получается совершенно наоборот и разница колоссальна -- 100 раз.
Непонятно, что делать, чтобы запрос работал одинаково хорошо. Может у кого нибудь есть мысли на эту тему или сталкивались с таким?
В какой то момент стал медленно выполняться отчет на СКД, когда установлен отбор по характеристике. На реальной базе вообще не выполняется. НО если настроить отбор через еще одну точку: вместо ВидПриемки = "Приемка1", установить ВидПриемки.Код = "1", то отчет работает также быстро как и раньше.
Полез смотреть в профайлер. Планы запросов разные и отличаются достаточно сильно. Ну это нормально. Но что вызвало у меня недопонимаение так это то, что для "быстрого" запроса Estimated SubStree Cost для последнего оператора показывает в 300 единиц в событии Showplan xml profile, а для "медленного" ESC = 12 единиц! Но уже в SQL:BatchCompleted "duration" у "быстрого" = 3000, у "медленного" = 300000.
Получается, что SQL Server предполагает, что один запрос будет быстрее другого в 25 раз, а получается совершенно наоборот и разница колоссальна -- 100 раз.
Непонятно, что делать, чтобы запрос работал одинаково хорошо. Может у кого нибудь есть мысли на эту тему или сталкивались с таким?
По теме из базы знаний
- Регистры сведений 1С. Как это устроено.
- 50+ советов для успешной сдачи 1С: Специалист по платформе
- Негативное влияние большого количества ролей на производительность 1С
- Как читать чужой код? Часть 3. Разбор и доработка запросов
- Быстрый фронт в базе размером 6.8 терабайт – наши стандарты при разработке и рефакторинге запросов
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(5) есть такая беда: статистика обновляется по порции данных. Порция может включать нерепрезентативную выборку.
Тогда статистика хоть и свежая - но некорректная. Попробуйте выполнить wirh fullscan для проблемной таблицы.
Если поможет то придется выключить автообновление статистики, оставив только запуск по расписанию.
Тогда статистика хоть и свежая - но некорректная. Попробуйте выполнить wirh fullscan для проблемной таблицы.
Если поможет то придется выключить автообновление статистики, оставив только запуск по расписанию.
(1) Была статейка одна от софтпоинта. Они там нашли, что если соединять по характеристикам без номенклатуры, то сильно проседала производительность, т.к. соединение не попадало в индекс. У Вас тут то же самое - не попадает в индекс отбор. Простое решение - всегда добавлять в отбор номенклатуру к характеристике.
(6)
Есть такое. В профайлере видно, что идет Индекс скан вместо идекс сика. Но это тоже странно, так как свойство хоть и второе измерение в РС "Значения свойст номенклатуры", но имеет флажок ведущее и в структуре хранения данных видно, что создан индекс по этому измерению.
Но вопрос не в том, что запрос медленно работает. А в том, что раньше работал быстро, а теперь стал медленно. Кроме того странная ситуация, что скл сервер предполагает, что "медленный" запрос должен работать быстрее "быстрого"
е попадает в индекс отбор. Простое решение - всегда добавлять в отбор номенклатуру к характер
Есть такое. В профайлере видно, что идет Индекс скан вместо идекс сика. Но это тоже странно, так как свойство хоть и второе измерение в РС "Значения свойст номенклатуры", но имеет флажок ведущее и в структуре хранения данных видно, что создан индекс по этому измерению.
Но вопрос не в том, что запрос медленно работает. А в том, что раньше работал быстро, а теперь стал медленно. Кроме того странная ситуация, что скл сервер предполагает, что "медленный" запрос должен работать быстрее "быстрого"
(7)
раньше работал быстро, а теперь стал медленно
Типичная ситуация при росте таблицы. Вчера в таблице было 99 строк и план запроса А, а сегодня 100 строк и sql строит уже совсем другой план.
скл сервер предполагает, что "медленный" запрос должен работать быстрее "быстрого"
это ошибка планировщика, скорее всего из-за статистики
Если отчет самописный, то первым пакетом создать ВТ отбора номенклатуры
относительно "легкой" таблицы Справочник.Номенклатура
Такой прием избавит СКД от излишнего рвения, когда в таблицы оборотных регистров
вставляются тяжелые фильтры В ИЕРАРХИИ, по характеристикам и т.п.
относительно "легкой" таблицы Справочник.Номенклатура
Выбрать
Т.Ссылка КАК ТоварыОтбора // НЕ задавать синоним поля как Номенклатура, иначе СКД раскидает отборы далее по пакетам согласно своим предпочтениям.
....
ПОМЕСТИТЬ ВтТоварыОтбора
Из Справочник.Номенклатура КАК Т
{ ... тут поля отборов, в том числе по характеристикам и пр...}
;
// далее пакеты логики отчета, в которые вставляем отбор по Номеклатуре как
// Где Т.Номенклатура В (Выбрать Т.ТоварыОтбора Из ВтТоварыОтбора КАК Т) ПоказатьТакой прием избавит СКД от излишнего рвения, когда в таблицы оборотных регистров
вставляются тяжелые фильтры В ИЕРАРХИИ, по характеристикам и т.п.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот