Гость
Войти | Профиль | Очистить
Действия ...
Форумы / Microsoft SQL Server [игнор отключен] [закрыт для гостей] / Почему настолько отличается скорось выполнения запроса ? / 25 сообщений из 37, страница 1 из 2
  1  все
21.09.2011, 18:36
    #37450471
iboobel
iboobel
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Почему настолько отличается скорось выполнения запроса ?
Добрый день всем!

Есть вот такой запрос:

Код: plaintext
1.
2.
SELECT table1.field1
from table1, (select table2 from table2 where table2.date_id >= '20110101     0     0' and table2.date_id < '20110102     0     0') as tmp
where table1.field2= tmp.field2

Выполняется быстро, конструкции подсмотрел через профайлер в 1с

но если вот это '20110101 0 0' перенести в переменную - тогда время увеличивается в десятки раз.

например:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
DECLARE @date_start
DECLARE @date_end
set @date_start = "манипуляции с датой"+'     0     0'
set @date_end = "манипуляции с датой"+'     0     0'

SELECT table1.field1
from table1, (select table2 from table2 where table2.date_id >= @date_start and table2.date_id < @date_end) as tmp
where table1.field2= tmp.field2

Почему так?
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
21.09.2011, 18:38
    #37450474
Гавриленко Сергей Алексеевич
Гавриленко Сергей Алексеевич
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Почему настолько отличается скорось выполнения запроса ?
Потому что запросы разные. И, скорее всего, с разным планом.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
21.09.2011, 18:45
    #37450484
iboobel
iboobel
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Почему настолько отличается скорось выполнения запроса ?
А чем они разные ?
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
21.09.2011, 18:47
    #37450488
iljy
iljy
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Почему настолько отличается скорось выполнения запроса ?
iboobelА чем они разные ?
Тем, что в одном случае сервер знает накладываемые ограничения, а в другом - нет.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
21.09.2011, 18:49
    #37450494
iljy
iljy
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Почему настолько отличается скорось выполнения запроса ?
iboobel,

уточню: знает накладываемые ограничения во время компиляции .
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
21.09.2011, 18:49
    #37450495
мопед не мой
мопед не мой
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Почему настолько отличается скорось выполнения запроса ?
http://www.sql.ru/blogs/somewheresomehow

последние(на данный момент) три статьи.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
21.09.2011, 18:49
    #37450496
iboobel
iboobel
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Почему настолько отличается скорось выполнения запроса ?
iljyiboobelА чем они разные ?
Тем, что в одном случае сервер знает накладываемые ограничения, а в другом - нет.
И ему приходится перебирать всю таблицу и сравнивать с переменной ? правильно я понял ?
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
21.09.2011, 18:52
    #37450498
iljy
iljy
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Почему настолько отличается скорось выполнения запроса ?
iboobeliljyпропущено...

Тем, что в одном случае сервер знает накладываемые ограничения, а в другом - нет.
И ему приходится перебирать всю таблицу и сравнивать с переменной ? правильно я понял ?
Неправильно. В случае констант сервер может более точно оценить количество выбираемых записей и соответственно оптимизировать выполнение. Посмотрите в план уже наконец.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
21.09.2011, 19:08
    #37450519
iboobel
iboobel
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Почему настолько отличается скорось выполнения запроса ?
Посмотрел, видно что в первом случае перебрал 18 000 строк, в другом 1 500 000
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
21.09.2011, 19:17
    #37450531
iljy
iljy
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Почему настолько отличается скорось выполнения запроса ?
iboobelПосмотрел, видно что в первом случае перебрал 18 000 строк, в другом 1 500 000
И все? При тех же значениях параметров? Быть такого не может, должны еще операции отличаться.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
21.09.2011, 19:19
    #37450533
мопед не мой
мопед не мой
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Почему настолько отличается скорось выполнения запроса ?
может у вас после манипуляций с датами совсем другие значения получаются?
вы проверяли?
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
21.09.2011, 19:27
    #37450548
VladimirKr
VladimirKr
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Почему настолько отличается скорось выполнения запроса ?
iboobel,
Данные достаете видимо из таблиц _1SENTRY, _1SJOURN или из регистров...

А зачем так длинно:
set @date_start = "манипуляции с датой"+' 0 0'

вполне достаточно:
DATE_TIME_IDDOC>='20110921' and DATE_TIME_IDDOC<'20110922'

И еще, иногда бывает очень полезно добавить в индексы, где индексируется DATE_TIME_IDDOC, включенные столбцы с необходимыми для выборки данными.
1С 7.7 такие манипуляции с индексами терпит.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
21.09.2011, 19:36
    #37450561
iboobel
iboobel
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Почему настолько отличается скорось выполнения запроса ?
Сори, таки отличаются.

В первом случае (время более минуты)
clustered index scan (cost 93 %) >>> Parallelism (cost 7%) >>> Select (cost 0%)

В другом (время 1 секунда)
index seek (cost 0%) >>> bookmark lookup 100% >>> select 0%
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
21.09.2011, 19:41
    #37450569
iboobel
iboobel
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Почему настолько отличается скорось выполнения запроса ?
VladimirKr, да из регистров )
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
21.09.2011, 19:49
    #37450579
VladimirKr
VladimirKr
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Почему настолько отличается скорось выполнения запроса ?
iboobel,
Дык попробуйте убрать bookmark lookup включенными столбцами, если столбцов немного.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
21.09.2011, 20:01
    #37450592
iljy
iljy
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Почему настолько отличается скорось выполнения запроса ?
iboobelСори, таки отличаются.

В первом случае (время более минуты)
clustered index scan (cost 93 %) >>> Parallelism (cost 7%) >>> Select (cost 0%)

В другом (время 1 секунда)
index seek (cost 0%) >>> bookmark lookup 100% >>> select 0%
Проще всего задать принудительно использование индекса with index...
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
21.09.2011, 21:02
    #37450651
step_ks
step_ks
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Почему настолько отличается скорось выполнения запроса ?
VladimirKriboobel,
Дык попробуйте убрать bookmark lookup включенными столбцами, если столбцов немного.
запрос с букмарком вроде автора вполне устраивает
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
22.09.2011, 11:39
    #37451305
iboobel
iboobel
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Почему настолько отличается скорось выполнения запроса ?
step_ksVladimirKriboobel,
Дык попробуйте убрать bookmark lookup включенными столбцами, если столбцов немного.
запрос с букмарком вроде автора вполне устраивает
Да, вполне устраивает.
Я не совсем понял они по разному выполняются, сделал через exec (@sql) и временную таблицу.

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
SET @sql = 'select table2 into #temptable from table2 where table2.date_id >='+@date_start+' and table2.date_id < '+@date_end+'

exec (@sql)

SELECT table1.field1
from table1, #temptable
where table1.field2= #temptable.field2

Может не очень феншуйно, но работает
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
22.09.2011, 11:45
    #37451325
iap
iap
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Почему настолько отличается скорось выполнения запроса ?
iboobelstep_ksпропущено...

запрос с букмарком вроде автора вполне устраивает
Да, вполне устраивает.
Я не совсем понял они по разному выполняются, сделал через exec (@sql) и временную таблицу.

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
SET @sql = 'select table2 into #temptable from table2 where table2.date_id >='+@date_start+' and table2.date_id < '+@date_end+'

exec (@sql)

SELECT table1.field1
from table1, #temptable
where table1.field2= #temptable.field2

Может не очень феншуйно, но работает Сказки рассказываете!
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
22.09.2011, 11:45
    #37451326
step_ks
step_ks
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Почему настолько отличается скорось выполнения запроса ?
iboobelЯ не совсем понял они по разному выполняются, сделал через exec (@sql) и временную таблицу.

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
SET @sql = 'select table2 into #temptable from table2 where table2.date_id >='+@date_start+' and table2.date_id < '+@date_end+'

exec (@sql)

SELECT table1.field1
from table1, #temptable
where table1.field2= #temptable.field2

Может не очень феншуйно, но работает
временная таблица то зачем? сразу без into пишите тогда уж. Или у вас там не так все просто как вы показываете?
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
22.09.2011, 11:46
    #37451333
step_ks
step_ks
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Почему настолько отличается скорось выполнения запроса ?
и как это вы так ловко поймали снаружи созданную в exec-е таблицу с одной решеткой?
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
22.09.2011, 11:47
    #37451334
Критик
Критик
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Почему настолько отличается скорось выполнения запроса ?
так попробуйте

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
DECLARE @date_start
DECLARE @date_end
set @date_start = "манипуляции с датой"+'     0     0'
set @date_end = "манипуляции с датой"+'     0     0'

SELECT table1.field1
from table1, (select table2 from table2 where table2.date_id >= @date_start and table2.date_id < @date_end) as tmp
where table1.field2= tmp.field2
option(recompile)
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
22.09.2011, 11:48
    #37451337
Shakill
Shakill
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Почему настолько отличается скорось выполнения запроса ?
step_ks, таблица создаётся где-то раньше, а не в экзеке
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
22.09.2011, 11:50
    #37451346
step_ks
step_ks
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Почему настолько отличается скорось выполнения запроса ?
Shakillstep_ks, таблица создаётся где-то раньше, а не в экзеке
а зачем тогда показывать , что создается в экзеке?
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
22.09.2011, 11:53
    #37451352
Shakill
Shakill
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Почему настолько отличается скорось выполнения запроса ?
step_ksа зачем тогда показывать , что создается в экзеке?
могу только предположить, что таблица создана два раза - и снаружи, и в динамике
пусть ТС сам скажет )
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
  1  все
Форумы / Microsoft SQL Server [игнор отключен] [закрыт для гостей] / Почему настолько отличается скорось выполнения запроса ? / 25 сообщений из 37, страница 1 из 2
Целевая тема:
Создать новую тему:
Автор:
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
созд. / загр.: 148ms
Закрыть
start [/forum/topic.php?fid=46&mobile=1&tid=1707992]:
 0ms
get settings:
 8ms
get forum list:
 10ms
check forum access:
 3ms
check topic access:
 3ms
track hit:
 28ms
get topic data:
 11ms
get forum data:
 3ms
get page messages:
 69ms
get tp. blocked users:
 2ms
others: 11ms
total:  148ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]