|
|
|
Оптимизатор
|
|||
|---|---|---|---|
|
#18+
Добрый день. Разбираюсь с оптимизация запросов и сразу же возникло несколько вопросов. Как я понял, оптимизатор запросов может оптимизировать только SQL запросы (insert, update, select), а выражения присущие только T-SQL(if, for) не может. Это так, или я ошибаюсь ? А если у меня запрос вида: for ..... insert ... select ..... Оптимизатор оптимизирует выражение внутри for' а ? Спасибо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.10.2002, 11:36:02 |
|
||
|
Оптимизатор
|
|||
|---|---|---|---|
|
#18+
Оптимизатор вначале выполняет декомпозицию запросов. ОСтаниется ли после этого Ваш for - это ещё не факт. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.10.2002, 12:09:03 |
|
||
|
Оптимизатор
|
|||
|---|---|---|---|
|
#18+
В описании оптимизатора встречается такая фраза: Cheapest cost is greater than parallelism threshold ? Что это за порог (parallelism threshold) ? Спасибо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.10.2002, 14:59:50 |
|
||
|
Оптимизатор
|
|||
|---|---|---|---|
|
#18+
Выполнять декомпозицию запроса через for - это, по-моему, чересчур - для такой оптимизации надо уже понимать логику запроса. Порог - если при составлении плана оптимизатор находит estimated cost больше некоторого значения, используются параллель. планы запросов. См. cost threshold for parallelism Option в BOL ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.10.2002, 16:12:01 |
|
||
|
Оптимизатор
|
|||
|---|---|---|---|
|
#18+
Thanks. Еще один вопрос, все по той же теме. Что такое Bookmark Lookup на Excution Plan ? И почему при выполнении одного и того же запроса на одной машине он присутствуе, а на другой нет ? Как можно снизить его стоимость ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.10.2002, 18:11:27 |
|
||
|
Оптимизатор
|
|||
|---|---|---|---|
|
#18+
А запросы выполняются на одном и том же сервере с теми же параметрами? Не верю. Bookmark lookup происходит, например, когда отбираются записи из некой таблицы по индексу с проверкой каких-нибудь условий, а потом нужно извлечь другие поля из этой таблицы, которых нет в индексе или проверить какие-то другие условия. Тогда при первом отборе "выдергиваются" id записей (создаются букмарки), а потом по ним идет обращение непосредственно к записям в этой таблице. Избавиться можно созданием составного индекса по всем полям, по которым идет выборка из таблицы. Но плодить много индексов на таблицу, данные в которой часто изменяются, не следует... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.11.2002, 01:12:42 |
|
||
|
Оптимизатор
|
|||
|---|---|---|---|
|
#18+
Спасибо. Да, вы правы. Хотя запрос один и тот же, и выполняется он над одним и тем же набором данных, но серверы разные. Вычитал еще одну интересную мыслю. Как я понял, если в моем запросе используются переменные, то статистика по индексам не используется. То есть даже если я делаю так: declare @t varchar(10) set @t = 'aaa' select * from table where field = @t То оптимизатор не сможет использовать статистику по индексам. Это так ? Если это так, то насколько это увеличит стоимость запроса (одно дело если это десятые доли процента, другое дело десятки процентов) ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.11.2002, 11:25:31 |
|
||
|
|

start [/forum/topic.php?fid=46&msg=32063499&tid=1819155]: |
0ms |
get settings: |
11ms |
get forum list: |
13ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
38ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
37ms |
get tp. blocked users: |
1ms |
| others: | 235ms |
| total: | 353ms |

| 0 / 0 |
