------------------------------------------------- запрос
insert #Q
select q.Questionniare_ID,q.TimeBegin,q.TimeEnd,q.Call_ID
from report.dbo.Questionniare q
where q.TimeBegin between @DateBegin and @DateEnd
and q.TaskID in (900,984)
print Convert(varchar(30), DateDiff(second, getdate(), @DT_CNT)) + ':  #Q ';

insert #Q
select q.Questionniare_ID,q.TimeBegin,q.TimeEnd,q.Call_ID
from control.dbo.Questionniare q
where q.TimeBegin between @DateBegin and @DateEnd
and q.TaskID in (900,984)
print Convert(varchar(30), DateDiff(second, getdate(), @DT_CNT)) + ':  #Q2 ';

insert #D
select d.Nau_session_id,d.Nau_seance_id,d.TimeBegin,d.TimeEnd,d.WaitAns,Input
from report.dbo.Dial d
where d.Questionniare_ID in (select Questionniare_ID from #Q)
print Convert(varchar(30), DateDiff(second, getdate(), @DT_CNT)) + ':  #D ';

insert #D
select d.Nau_session_id,d.Nau_seance_id,d.TimeBegin,d.TimeEnd,d.WaitAns,Input
from control.dbo.Dial d
where d.Questionniare_ID in (select Questionniare_ID from #Q)
print Convert(varchar(30), DateDiff(second, getdate(), @DT_CNT)) + ':  #D2 ';

insert #CL
select cl.SESSION_ID,cl.LEG_ID,cl.ENDED
from Firebird.dbo.call_legs cl with(nolock)
where 1=1
and cl.CREATED between @DateBegin and @DateEnd
and cl.SESSION_ID in ( select Nau_Session_ID from #D  D with (INDEX = IX2_D ))
print Convert(varchar(30), DateDiff(second, getdate(), @DT_CNT)) + ':  CL ';

-------------------------------------------------вывод:
(строк обработано: 4927)
(строк обработано: 1)
-8:  #Q
(строк обработано: 0)
(строк обработано: 1)
-8:  #Q2
(строк обработано: 4897)
(строк обработано: 1)
-11:  #D
(строк обработано: 0)
(строк обработано: 1)
-11:  #D2
(строк обработано: 17511)
(строк обработано: 1)
-112:  CL
------------------------------

видно, что самое тяжелое CL, почти 100 секунд
-----------------

план (действительный)
http://uploads.ru/O28Ya.jpg

------------------

вопрос: А как же так?! Почему план (действительный!) показывает 92% на самый первый запрос?

возможно, оптимизатор 1-й раз кэширует какие-то запросы
where q.TimeBegin between @DateBegin and @DateEnd
and q.TaskID in (900,984)

поменяй их местами последний первым и т.д. если это кеш и первые запросы в память с сохранением на последнем (или ожиданием завершения) то будет то же самое. т.е. большее время опять будет на последнем, который сейчас первый.

+
кстати
> where 1=1
?
нафига? вообще тогда условие убери.

> where 1=1

издержки формирования запроса динамически в коде?
сиквельный оптимизатор наверно должен сам это убрать

> поменяй их местами

нельзя
D на основе Q
CL на основе D

> where 1=1
оптимизатор убирает
а так удобнее условия and дописывать/коментировать
просто первый and закоментишь - ругается. А так нет
но это ладно

просто..  ладно бы это был ожидаемый план. Так действительный же..
Кэш.. Ну да, наверное.. как иначе объяснить

> [4] ВладОшин ©   (04.08.14 21:15)
> а так удобнее условия and дописывать/коментировать
> просто первый and закоментишь - ругается. А так нет

where
 cond1
//  and cond2
 and cond3
; // тоже для удобства отладки

Ну ты это и написал же.

а если cond1 теперь надо закомментировать, то придется что-то еще менять
можно так еще попробовать привыкнуть

where
cond1 and
cond2 and
cond3

тогда

where
-- cond1 and
cond2 and
cond3
и прокатит

но

where
cond1 and
cond2 and
-- cond3
и опять надо подправлять

а
where 1=1
and cond1
and cond2
and cond3
любое комментим, и ничего не правим, что бы посмотреть как оно получится

и логично, имхо:
Выбери [все]  
   и [что бы 1]
   и [что бы 2]
   и [что бы 3]

для, именно отладки(/тестирования) нужно стараться избегать лишнего. особенно когда возникает что то странное.
проблема может быть именно в этом на первый взгляд понятном коде. врядли конечно, но я к примеру встречал ситуацию когда приблизительно такой код вводил sql сервер (уж не помню какой но скорее всего информикс, больше всего "непоняток" было с ним) в "ступор", оптимизатор почему то считал это вычисляемым условием, что приводило к перебору всей таблицы несмотря на то, что следующее условие явно указывало на единичную выборку по ключу.

переписал нормально, без 1=1.
Из кэша за сутки точно вылетело все.

Результат тот же.
(даже по секундам хуже)

>  from Firebird.dbo.call_legs
это табла постоянно пополняется из FB БД (кроме того что большая весьма)
походу он не может зафиксировать момент когда записываться закончит (пишется постоянно, причем не нами, а "ими". Для них доступ открыт на запись, а не для нас к ним на чтение)