|
Можно ли существенно оптимизировать данную процедуру.
|
||
|---|---|---|
Участник
Откуда: Moscow
Сообщения: 2 471 |
||
| 20.06.2013, 16:07 |
|
|
|
|
|
Можно ли существенно оптимизировать данную процедуру.
|
|||
|---|---|---|---|
|
#18+
Вот тут http://www.sqlservercentral.com/articles/T-SQL/68467/ чрезвычайно крутецкое исследование + методология безопасного использования "стремного апдейта" В случае TL;DR можно сразу листать к "The RULES" Касаемо быстродействия ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.06.2013, 15:40 |
|
||
|
Можно ли существенно оптимизировать данную процедуру.
|
|||
|---|---|---|---|
|
#18+
Касаемо быстродействия авторAnother choice is to use both the "Quirky Update" and the code that verifies it. Even if you copy the required data to a Temp Table (20 secs), do the update (6 secs), use the verification code (10 secs), and then update the original table (14 secs), it will still be almost 10 times faster than RBAR. On my machine, the Cursor method took almost 8 minutes to do just 1 running total. Running the full gambit of "Quirky Update" and "Verification" code including the creation of a separate verification table (which I'd only do for "in-place" updates) only took 50 seconds. Remember... that's on a million rows on a 7 year old non-server quality box. ps прошу прощения за 3 поста, это привычка нажимать ктрл+ентер чтобы сделать перенос строкив окне... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.06.2013, 15:41 |
|
||
|
Можно ли существенно оптимизировать данную процедуру.
|
|||
|---|---|---|---|
|
#18+
Cammomile+ методология безопасного использования "стремного апдейта" Т.е. использование некого "быстрого" запроса оказывается возможно лишь при соблюдении "мер безопасности" ? И это должно сподвигнуть меня в сторону отказа от курсора ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.06.2013, 15:46 |
|
||
|
Можно ли существенно оптимизировать данную процедуру.
|
|||
|---|---|---|---|
|
#18+
Речь шла о быстродействии. Вот наглядный пример, где быстрый запрос + меры безопасности лучше курсора для типа задач который вы привели "в защиту" курсоров. Также изначально было сказано одним из пользователей, что мол курсоры несильно влияют на скорость. Курсоры не могут несильно влиять на скорость, особенно на больших объемх данных. Хотяб потому, что в курсоре количество операций больше чем в цикле по таблице, коим является селект\апдейт. Об этом я пишу. Также люди пишут, что апдейт с использованием новых функций в 2012 лучше курсора в разы. Вот, собственно, весь хрен до копейки. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.06.2013, 15:53 |
|
||
|
Можно ли существенно оптимизировать данную процедуру.
|
|||
|---|---|---|---|
|
#18+
И я не агитирую за "отказ от курсоров" что вы мне тут приписываете на ровном месте! Каждому случаю -- подходящий инструмент. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.06.2013, 15:54 |
|
||
|
Можно ли существенно оптимизировать данную процедуру.
|
|||
|---|---|---|---|
|
#18+
Было уже много разговоров про курсоры, можно поискать по форуму. Лично я использую курсоры для выполнения exec процедур в цикле, иногда нужно. Хотя, даже в таких случаях, можно обойтись динамикой, но мне это кажется не очень удобным. Касательно нарастающего итога, недавно на devcon разговаривал с докладчиком из sql cat, и что-то зашла речь про нарастающий итог. Я высказался что-то типа "хорошо, сейчас оконными функциями можно считать", на что на меня странно посмотрели и сказали, что "лучше держать его уже посчитанным", и, черт возьми, нельзя не согласиться - крайне быстрый способ =) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.06.2013, 16:07 |
|
||
|
Можно ли существенно оптимизировать данную процедуру.
|
|||
|---|---|---|---|
|
#18+
SomewhereSomehowБыло уже много разговоров про курсоры, можно поискать по форуму. Лично я использую курсоры для выполнения exec процедур в цикле, иногда нужно. Хотя, даже в таких случаях, можно обойтись динамикой, но мне это кажется не очень удобным. Касательно нарастающего итога, недавно на devcon разговаривал с докладчиком из sql cat, и что-то зашла речь про нарастающий итог. Я высказался что-то типа "хорошо, сейчас оконными функциями можно считать", на что на меня странно посмотрели и сказали, что "лучше держать его уже посчитанным", и, черт возьми, нельзя не согласиться - крайне быстрый способ =) насчет "лучше держать уже подсчитанным" тоже пардон смешно. Случаи разные бывают. Вообще бест практис - иметь итоги сгруппированные по дню. Ибо внутри дня нарастающие итоги по каждой транзакии иметь - overhead. А сгруппированные суммы до дня - легко считать хоть каким методом ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.06.2013, 17:26 |
|
||
|
|
start [/forum/topic.php?fid=46&gotonew=1&tid=1706505]: |
0ms |
get settings: |
11ms |
get forum list: |
12ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
39ms |
get topic data: |
11ms |
get first new msg: |
8ms |
get forum data: |
2ms |
get page messages: |
50ms |
get tp. blocked users: |
1ms |
| others: | 266ms |
| total: | 408ms |
| 0 / 0 |
