При соединении hash match сильно ошибается в оценке
На скрине видно, что изначально оптимизатор правильно оценивает поиски в индексах. Но потом hash match очень сильно ошибается.
Ошибка это выливается в то, что запрос выполняется бесконечно. Этот скрин только где то в процессе выполнения.
Чистка кэша не помогла, статистику по этим таблицам обновил, создал дополнительно свою по полям, индексы все есть. Такое ощущение что оптимизатор для hash match вообще не пытался оценить нагрузку. Просто от балды поставил единицу.
Хоть подскажите куда копнуть.
Сам запрос.
Ошибка это выливается в то, что запрос выполняется бесконечно. Этот скрин только где то в процессе выполнения.
Чистка кэша не помогла, статистику по этим таблицам обновил, создал дополнительно свою по полям, индексы все есть. Такое ощущение что оптимизатор для hash match вообще не пытался оценить нагрузку. Просто от балды поставил единицу.
Хоть подскажите куда копнуть.
Сам запрос.
SEL ECT
T1.Fld48271RRef
FR OM (SEL ECT
T4._Fld48270RRef AS Fld48270RRef,
T4._Fld48284RRef AS Fld48284RRef,
T4._Period AS Period_,
T4._Fld48268 AS Fld48268_,
T4._Fld48271RRef AS Fld48271RRef
FR OM (SEL ECT
T3._Fld48268 AS Fld48268_,
T3._Fld48269RRef AS Fld48269RRef,
T3._Fld48270RRef AS Fld48270RRef,
T3._Fld48283 AS Fld48283_,
T3._Fld48284RRef AS Fld48284RRef,
MAX(T3._Period) AS MAXPERIOD_
FROM dbo._InfoRg48267 T3 WITH(NOLOCK)
GROUP BY T3._Fld48268,
T3._Fld48269RRef,
T3._Fld48270RRef,
T3._Fld48283,
T3._Fld48284RRef) T2
INNER JOIN dbo._InfoRg48267 T4 WITH(NOLOCK)
ON T2.Fld48268_ = T4._Fld48268 AND T2.Fld48269RRef = T4._Fld48269RRef AND T2.Fld48270RRef = T4._Fld48270RRef AND T2.Fld48283_ = T4._Fld48283 AND T2.Fld48284RRef = T4._Fld48284RRef AND T2.MAXPERIOD_ = T4._Period) T1
INNER JOIN (SELECT
MAX(T6.Period_) AS Q_001_F_000_,
T6.Fld48268_ AS Q_001_F_001_
FR OM (SELECT
T9._Fld48270RRef AS Fld48270RRef,
T9._Period AS Period_,
T9._Fld48268 AS Fld48268_
FR OM (SELECT
T8._Fld48268 AS Fld48268_,
T8._Fld48269RRef AS Fld48269RRef,
T8._Fld48270RRef AS Fld48270RRef,
T8._Fld48283 AS Fld48283_,
T8._Fld48284RRef AS Fld48284RRef,
MAX(T8._Period) AS MAXPERIOD_
FR OM dbo._InfoRg48267 T8 WITH(NOLOCK)
GROUP BY T8._Fld48268,
T8._Fld48269RRef,
T8._Fld48270RRef,
T8._Fld48283,
T8._Fld48284RRef) T7
INNER JOIN dbo._InfoRg48267 T9 WITH(NOLOCK)
ON T7.Fld48268_ = T9._Fld48268 AND T7.Fld48269RRef = T9._Fld48269RRef AND T7.Fld48270RRef = T9._Fld48270RRef AND T7.Fld48283_ = T9._Fld48283 AND T7.Fld48284RRef = T9._Fld48284RRef AND T7.MAXPERIOD_ = T9._Period) T6
WH ERE (T6.Fld48270RRef =0xB328F024F15FB7774F44540770EB21DF)
GROUP BY T6.Fld48268_) T5
ON (T1.Period_ = T5.Q_001_F_000_) AND (T1.Fld48268_ = T5.Q_001_F_001_)
WH ERE (T1.Fld48270RRef = 0xB328F024F15FB7774F44540770EB21DF) AND (T1.Fld48284RRef = 0xAB6D22A9362352904E682CDD31C4F3C9)
GROUP BY T1.Fld48271RRef
ПоказатьПрикрепленные файлы:
По теме из базы знаний
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(2) Согласен. Это типовые срезы последних скорей всего. Исходный запрос на 1С пока не нашел. Я больше про оценки оптимизатора. Ведь оптимизатор правильно определил кол строк в исходных таблицах, откуда единица в соединении этих таблиц потом. Явно бред какой-то. Вот и подумал что можно чтото докрутить в сервере. Флаг трассировки какойнить и т.д.
Вообщем это было соединение со срезом последних. Вынес в отдельную временную таблицу срез последних и проблема решилась но осталось для меня загадкой. Думаю оптимизатор не смог просчитать. Как подсказали выше у меня старый оптимизатор.
(11) в самом первом операторе надо было посмотреть на уровень оптимизации и успел ли оптимизатор правильно посчитать. Вполне вероятно не хватило времени полноценно оценить статистику таблиц.
Кстати, когда в операторе предполагается 1 строка, это не всегда 1. Когда оптимизатор считает, что оператор вернет 0 строк, тоже ставит 1
Кстати, когда в операторе предполагается 1 строка, это не всегда 1. Когда оптимизатор считает, что оператор вернет 0 строк, тоже ставит 1
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот