Исходные:
1с 77
MS SQL 2008 R2
1c++
Проблема:
Есть один запрос, который начинает тормозить если его формируешь по новому складу. Т.е. выбираешь склад1 - время выполнения несколько секунд, выбираешь склад2 - время выполнения около получаса.
Текст запроса и планы запроса ниже

1с++ запрос

SELECT
    Запр3.Товар Товар
,    RIGHT(Запр3.Поставка, 9) СтранаПоставщик
,    CAST(LEFT(Запр3.Поставка, 8) AS DateTime) Дата
FROM (
SELECT
    Запр2.Товар Товар
,    MAX(Журнал2.DATE_TIME_IDDOC + Запр2.СтранаПоставщик) Поставка
FROM (
SELECT DISTINCT
    Запр.Товар Товар
,    $СпрКонтрДоп.СтранаПоставщик СтранаПоставщик
,    Запр.Поставка Поставка
FROM (
SELECT DISTINCT
    $РегТПС.Товар Товар
,    $РегТПС.Поставщик Поставщик
,    RIGHT($РегТПС.Поставка,9) Поставка
FROM
    $Регистр.ТоварыПоСкладам РегТПС (NoLock)
WHERE
    (РегТПС.Date_Time_IDDoc BETWEEN :ДатаНач AND :ДатаКон~)
    AND ($РегТПС.Склад = :Склад)
    AND ($РегТПС.ВидДвижения IN ('   4VM   ','   4VK   ','   4VL   ' ))
    
    AND $РегТПС.Товар IN (SELECT Val FROM #Тов)


UNION ALL

SELECT
    РегОстТПС.Товар Товар
,    РегОстТПС.Поставщик Поставщик
,    RIGHT(РегОстТПС.Поставка,9) Поставка
FROM
    $РегистрОстатки.ТоварыПоСкладам(:ДатаКон~,,(Склад = :Склад) AND (Товар IN (SELECT Val FROM #Тов)),(Товар,Поставщик,Поставка),(ОстатокТовара)) РегОстТПС
) as Запр
INNER JOIN
    $Справочник.Контрагенты СпрКонтрДоп (NoLock) ON СпрКонтрДоп.ID = Запр.Поставщик
) as Запр2
INNER JOIN
    _1sJourn Журнал2 (NoLock) ON Журнал2.IDDoc = RIGHT(Запр2.Поставка,9)
GROUP BY
    Запр2.Товар
) as Запр3


T-SQL запрос

SELECT
    Запр3.Товар Товар
,    RIGHT(Запр3.Поставка, 9) СтранаПоставщик
,    CAST(LEFT(Запр3.Поставка, 8) AS DateTime) Дата
FROM (
SELECT
    Запр2.Товар Товар
,    MAX(Журнал2.DATE_TIME_IDDOC + Запр2.СтранаПоставщик) Поставка
FROM (
SELECT DISTINCT
    Запр.Товар Товар
,    СпрКонтрДоп.sp5847 СтранаПоставщик
,    Запр.Поставка Поставка
FROM (
SELECT DISTINCT
    РегТПС.sp5421 Товар
,    РегТПС.sp5424 Поставщик
,    RIGHT(РегТПС.sp5423,9) Поставка
FROM
    ra5420 РегТПС (NoLock)
WHERE
    (РегТПС.Date_Time_IDDoc BETWEEN '20150820' AND '20150916Z')
    AND (РегТПС.sp5422 = '    7ICEN')
--    AND (РегТПС.sp5422 = '    7PRAD')
    AND (РегТПС.sp6327 IN ('   4VM   ','   4VK   ','   4VL   ' ))
    AND РегТПС.sp5421 IN (SELECT Val FROM #Тов)


UNION ALL

SELECT
    РегОстТПС.Товар Товар
,    РегОстТПС.Поставщик Поставщик
,    RIGHT(РегОстТПС.Поставка,9) Поставка
FROM
    (
select
rg5420_vt.sp5421 as Товар,
rg5420_vt.sp5424 as Поставщик,
rg5420_vt.sp5423 as Поставка,
sum(rg5420_vt.sp5425) as ОстатокТовараОстаток
from rg5420 as rg5420_vt (nolock)
where rg5420_vt.period={d '2015-09-01'}
and ((rg5420_vt.sp5422 = '    7ICEN') AND (rg5420_vt.sp5421 IN (SELECT Val FROM #Тов)))
--and ((rg5420_vt.sp5422 = '    7PRAD') AND (rg5420_vt.sp5421 IN (SELECT Val FROM #Тов)))
group by
rg5420_vt.sp5421,
rg5420_vt.sp5424,
rg5420_vt.sp5423
having
sum(rg5420_vt.sp5425) <> 0
) as РегОстТПС
) as Запр
INNER JOIN
    sc46 СпрКонтрДоп (NoLock) ON СпрКонтрДоп.ID = Запр.Поставщик
) as Запр2
INNER JOIN
    _1sJourn Журнал2 (NoLock) ON Журнал2.IDDoc = RIGHT(Запр2.Поставка,9)
GROUP BY
    Запр2.Товар
) as Запр3


А статистику-то обновил?

короче проблема с отобращением плана тут - попозже файлом скину куда-нить
--------
(4) Да полное обновление статистики делал
сначала тожа была такая проблема - решилась обновление одной здоровой таблицы
сейчас это не помогает почему-то

быстрый план
https://yadi.sk/i/P6FVayvfj86JK
медленный план
https://yadi.sk/i/RfpRMC_0j86ME

(0) а зачем в этом запрсе смотреть движения регистра ? Когда всё и так есть в остатках ?..

ну и вот это
INNER JOIN
    $Справочник.Контрагенты СпрКонтрДоп (NoLock) ON СпрКонтрДоп.ID = Запр.Поставщик

можно попробовать пихнуть унутрь вт и первого запроса в юнион

Хотя, непонятен изначально сам запрос движений за период + останки..

Судя по планам, задействуется параллелизм. А по всем рекомендациям, его лучше отключать. Почему не отключен?

речь сейчас не об оптимизации запроса
вопрос почему при смене одного склада на другой резко падает скорость

(11) max DOP = 2

(13) поставь 1

(14) ставил OPTION (MAXDOP 1) - не помогло (
------
Похоже раскопал где собака порылась
на сервере max dop = 2
однако картинка в студии более интересная
там 4 блока по 5 строк в каждом
2 блока running
2 блока suspended
и походу они меняются др / др
а дело вроде в плевой строчке
CREATE TABLE #ПослПост (Товар Char(9), СтранаПоставщик Char(9), Дата DateTime, UNIQUE CLUSTERED (Товар))
а именно в индексе UNIQUE CLUSTERED (Товар)
пробовал просто UNIQUE (Товар) - тоже тормозит
количество строк в итоговой таблице около 1000
-----
убрал индекс и все залетало

Это случайно не paramers sniffing?

Хотя нет, не в нем

может темп дб умирает?

http://savepic.org/7721209.jpg

можешь планы в картинках показать?

(15) declare  @ПослПост TABLE (Товар Char(9), СтранаПоставщик Char(9), Дата DateTime, PRIMARY KEY CLUSTERED(Товар) )

(21) это типа в оперативке таблица?
что-то у нас этот вариант не приняли - глюки были

в скуле щас оба склада одинаково быстро выполняются
похоже проблема была в INSERT #ПослПост

кстати, про статистики
вот тут есть годные скрипты  http://blogs.msdn.com/b/blogdoezequiel/archive/2012/09/18/about-maintenance-plans-grooming-sql-server.aspx

и ещё, для 2008 параллелизм как раз таки лучше включить, там это наконец-то действительно работает.

сколько платят за проблему?

(24) параллелизм+1

Реально встречал случаи, когда параллелизм тормозил запросы в разы

(27) именно на 2008?

(28) Ага.
Но не спрашивай примеры, уже не помню.

Причём р2 64 бит со всеми сп

поторопился я с решением проблемы - сегодня снова тормоза - уже на запросе, а не на вставке во временную
будем копать дальше, пока другие задачи время отнимают
(25) уважуха и спасибо )

сегодня снова занимался этой проблемой
выяснил, что тормозит на строке
INNER JOIN _1sJourn Журнал2 (NoLock) ON Журнал2.IDDoc = RIGHT(Запр2.Поставка,9)
поменял на
INNER JOIN _1sJourn Журнал2 (NoLock) ON Журнал2.IDDoc = Запр2.Поставка
и запрос залетал
вообще странно т.к. записей в запр2 около тысячи, а вот в _1sJourn записей умотаться

т.е. тут уже не статистике дело, а в неверном плане запроса