|
Можно ли существенно оптимизировать данную процедуру.
|
|||
---|---|---|---|
#18+
Доброго вечера, уважаемые! Я небольшой спец в программировании, но приходится делать все самому, т.к. много мелких изменений постоянно, и проще переделать самому, чем долго искать спеца, да и не факт что сделают намного лучше. По-этому прошу ногами не пинать. Мною написано много подобных процедур, стиль написания будет понятен из листинга ниже. Можно ли существенно ускорить их выполнение? К примеру данный запрос выполняется секунд 20. Запросы идут потоком и в итоге все это долго. Если найдется спец который существенно ускорит данное безобразие - я готов заплатить. Может укажете на какие кардинальные ошибки? Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76.
... |
|||
:
Нравится:
Не нравится:
|
|||
19.06.2013, 22:46 |
|
Можно ли существенно оптимизировать данную процедуру.
|
|||
---|---|---|---|
#18+
dimon71, план выполнения у вас ест? смотрите план выполнения и вы сам будете исправит ошибки ... |
|||
:
Нравится:
Не нравится:
|
|||
19.06.2013, 22:55 |
|
Можно ли существенно оптимизировать данную процедуру.
|
|||
---|---|---|---|
#18+
dimon71Может укажете на какие кардинальные ошибки? 1) В теме не описаны исходные структуры; 2) В теме не описана сутьпроисходящего; 3) Код не обёрнут в соответствующий тег. dimon71Можно ли существенно ускорить их выполнение? К примеру данный запрос выполняется секунд 20. Запросы идут потоком и в итоге все это долго. Разбираться в этой некомементированной лапше нет никакого желания. Но навскидку весьма напоминает бред процедурного программиста, не понявшего суть SQL и плодящего итерационные циклы вместо одного простого запроса. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.06.2013, 23:50 |
|
Можно ли существенно оптимизировать данную процедуру.
|
|||
---|---|---|---|
#18+
natyaплан выполнения у вас есть? смотрите план выполнения и вы сам будете исправит ошибки Плюсую! Иногда достаточно индексы добавить/убрать, чтобы запрос начал летать. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.06.2013, 09:09 |
|
Можно ли существенно оптимизировать данную процедуру.
|
|||
---|---|---|---|
#18+
HelenMnatyaплан выполнения у вас есть? смотрите план выполнения и вы сам будете исправит ошибки Плюсую! Иногда достаточно индексы добавить/убрать, чтобы запрос начал летать. Интересуюсь, Сонечка, хдеж ты тут запрос то увидела? У тредстартера тупая императивная процедура, которая на раз заменяется одним MERGE. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.06.2013, 09:13 |
|
Можно ли существенно оптимизировать данную процедуру.
|
|||
---|---|---|---|
#18+
dimon71, Тут совет один — писать запросами а не курсорами. Вот зачем тебе там курсор? ... |
|||
:
Нравится:
Не нравится:
|
|||
20.06.2013, 09:24 |
|
Можно ли существенно оптимизировать данную процедуру.
|
|||
---|---|---|---|
#18+
Ув. автор топика, для простоты понимания, скажем так ,что Select * From [TableName] это типа как FOREACH Т.е. вы в селекте пройдете по каждой строке соответсвующей условию автоматически. Ровно также как при инсерте и апдейте. Т.е. вам надо для начала прочитать селект/инсерт/апдейт. Затем оформление хранимок. Затем начинать творить. Хотя курсоры и проходят указанный диапазон построчно, нужны они совсем для другого. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.06.2013, 09:30 |
|
Можно ли существенно оптимизировать данную процедуру.
|
|||
---|---|---|---|
#18+
dimon71, insert select и update from вместо курсора.. А вообще правильно сказали выше, изучите базовые инструкции T-SQL:) SELECT UPDATE INSERT ... |
|||
:
Нравится:
Не нравится:
|
|||
20.06.2013, 09:41 |
|
Можно ли существенно оптимизировать данную процедуру.
|
|||
---|---|---|---|
#18+
По хорошему, нам нужен отдельный faq по теме "как читать майкрософтовские хелпы". По своему опыту скажу, что конструкции типа автор [ <FOR Clause>] [ OPTION ( <query_hint> [ ,...n ] ) ] ввергают неокрепший разум в ужас и уныние. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.06.2013, 09:47 |
|
Можно ли существенно оптимизировать данную процедуру.
|
|||
---|---|---|---|
#18+
CammomileПо хорошему, нам нужен отдельный faq по теме "как читать майкрософтовские хелпы". По своему опыту скажу, что конструкции типа автор [ <FOR Clause>] [ OPTION ( <query_hint> [ ,...n ] ) ] ввергают неокрепший разум в ужас и уныние. Согласен с вами) А далее ещё: <query hint> ::= { } Но там всегда есть примеры, которые помогают осознать основные принципы, а далее просто время и разработка... ... |
|||
:
Нравится:
Не нравится:
|
|||
20.06.2013, 09:53 |
|
Можно ли существенно оптимизировать данную процедуру.
|
|||
---|---|---|---|
#18+
Cammomile, и другие уважаемые форумчане. Большое спасибо за советы. Все понял. Пошел исправляться. Насчет замены нараз всего этого одним запросом, думаю ничего не выйдет. Покопаюсь. Спасибо. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.06.2013, 10:16 |
|
Можно ли существенно оптимизировать данную процедуру.
|
|||
---|---|---|---|
#18+
dimon71Cammomile, и другие уважаемые форумчане. Большое спасибо за советы. Все понял. Пошел исправляться. Насчет замены нараз всего этого одним запросом, думаю ничего не выйдет. Покопаюсь. Спасибо. вам тут про оператор merge намекали, вот и начните чтение справочной информации с него ... |
|||
:
Нравится:
Не нравится:
|
|||
20.06.2013, 10:23 |
|
Можно ли существенно оптимизировать данную процедуру.
|
|||
---|---|---|---|
#18+
CammomileПо хорошему, нам нужен отдельный faq по теме "как читать майкрософтовские хелпы".По хорошему, все уже давно написано. Синтаксические обозначения в Transact-SQL (Transact-SQL) Расширенная форма Бэкуса — Наура ... |
|||
:
Нравится:
Не нравится:
|
|||
20.06.2013, 10:28 |
|
Можно ли существенно оптимизировать данную процедуру.
|
|||
---|---|---|---|
#18+
РБНФ; век живи--век учись. Спасибо коллега! ... |
|||
:
Нравится:
Не нравится:
|
|||
20.06.2013, 10:34 |
|
Можно ли существенно оптимизировать данную процедуру.
|
|||
---|---|---|---|
#18+
dimon71, Нет информации о размерах таблицы. Но 20 сек даже для миллиона записей много. Вряд ли в справочние товаров у Вас больше. Проверьте наличие и использование индексов. Использование курсоров не так уж критически сказывается на быстродействии. Зато намного наглядней алгоритм(скрипт). ... |
|||
:
Нравится:
Не нравится:
|
|||
20.06.2013, 10:54 |
|
Можно ли существенно оптимизировать данную процедуру.
|
|||
---|---|---|---|
#18+
"Использование курсоров не так уж критически сказывается на быстродействии." Вот за такое хочеться взять и у...бедить так больше никогда-никогда не писать. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.06.2013, 10:59 |
|
Можно ли существенно оптимизировать данную процедуру.
|
|||
---|---|---|---|
#18+
DirksDR,когда отработает расскажите нам, как там курсор сказывается на скорости выполнения, ок? Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32.
... |
|||
:
Нравится:
Не нравится:
|
|||
20.06.2013, 11:16 |
|
Можно ли существенно оптимизировать данную процедуру.
|
|||
---|---|---|---|
#18+
Cammomileхочеться ==>хочется ну почему тут нельзя редактировать посты (((( ... |
|||
:
Нравится:
Не нравится:
|
|||
20.06.2013, 11:17 |
|
Можно ли существенно оптимизировать данную процедуру.
|
|||
---|---|---|---|
#18+
dimon71Cammomile, и другие уважаемые форумчане. Большое спасибо за советы. Все понял. Пошел исправляться. Насчет замены нараз всего этого одним запросом, думаю ничего не . К сожалению, только так и надо. Эту процедуру надо заменить на два запроса insert update, или один merge. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.06.2013, 11:38 |
|
Можно ли существенно оптимизировать данную процедуру.
|
|||
---|---|---|---|
#18+
CammomileПо хорошему, нам нужен отдельный faq по теме "как читать майкрософтовские хелпы". По своему опыту скажу, что конструкции типа автор [ <FOR Clause>] [ OPTION ( <query_hint> [ ,...n ] ) ] ввергают неокрепший разум в ужас и уныние.Ну ладно, нормальный хелп, на русском языке, с примерами. А эти "конструкции типа" обязательно надо изучить, так описываются синтаксические конструкции у всех производителей, и в учебниках, не только у микрософта. Эти конструкции на самом деле очень просты, всего лишь нужно понять, что озачают 3 вида скобок, многоточие и запятая. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.06.2013, 11:44 |
|
Можно ли существенно оптимизировать данную процедуру.
|
|||
---|---|---|---|
#18+
Cammomile"Использование курсоров не так уж критически сказывается на быстродействии." Вот за такое хочеться взять и у...бедить так больше никогда-никогда не писать. А кто это писал? ... |
|||
:
Нравится:
Не нравится:
|
|||
20.06.2013, 11:45 |
|
Можно ли существенно оптимизировать данную процедуру.
|
|||
---|---|---|---|
#18+
CammomileПо хорошему, нам нужен отдельный faq по теме "как читать майкрософтовские хелпы". По своему опыту скажу, что конструкции типа автор [ <FOR Clause>] [ OPTION ( <query_hint> [ ,...n ] ) ] ввергают неокрепший разум в ужас и уныние. Вы не поверите, но про то, как читать майкрософтовские хелпы", есть в самом хелпе - Transact-SQL Syntax Conventions (Transact-SQL) ... |
|||
:
Нравится:
Не нравится:
|
|||
20.06.2013, 11:48 |
|
Можно ли существенно оптимизировать данную процедуру.
|
|||
---|---|---|---|
#18+
ну вот же DirksDRdimon71, Нет информации о размерах таблицы. Но 20 сек даже для миллиона записей много. Вряд ли в справочние товаров у Вас больше. Проверьте наличие и использование индексов. Использование курсоров не так уж критически сказывается на быстродействии. Зато намного наглядней алгоритм(скрипт). ... |
|||
:
Нравится:
Не нравится:
|
|||
20.06.2013, 11:48 |
|
Можно ли существенно оптимизировать данную процедуру.
|
|||
---|---|---|---|
#18+
Cammomile"Использование курсоров не так уж критически сказывается на быстродействии." Вот за такое хочеться взять и у...бедить так больше никогда-никогда не писать. Все зависит от конкретной задачи. И выигрывает всегда тот, кто знает больше способов. А не тот, у кого больше убеждений. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.06.2013, 11:51 |
|
Можно ли существенно оптимизировать данную процедуру.
|
|||
---|---|---|---|
#18+
Пример когда селект\инсерт\апдейт в курсоре быстрее чем без курсора в студию. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.06.2013, 11:55 |
|
Можно ли существенно оптимизировать данную процедуру.
|
|||
---|---|---|---|
#18+
CammomileПример когда селект\инсерт\апдейт в курсоре быстрее чем без курсора в студию. Выберите любую задачу, где важен _порядок_ обработки записей ... |
|||
:
Нравится:
Не нравится:
|
|||
20.06.2013, 11:57 |
|
Можно ли существенно оптимизировать данную процедуру.
|
|||
---|---|---|---|
#18+
Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24.
... |
|||
:
Нравится:
Не нравится:
|
|||
20.06.2013, 12:00 |
|
Можно ли существенно оптимизировать данную процедуру.
|
|||
---|---|---|---|
#18+
Все таки я бы хотел видеть конкретный пример. А не "любую" задачу. За 7 лет практики не припомню таких "любых" задач где курсор был бы быстрее. Задачи где без курсора просто никак - да, много. А мы же говорим за _быстрее_, правда? ... |
|||
:
Нравится:
Не нравится:
|
|||
20.06.2013, 12:02 |
|
Можно ли существенно оптимизировать данную процедуру.
|
|||
---|---|---|---|
#18+
CammomileВсе таки я бы хотел видеть конкретный пример. А не "любую" задачу. Да легко Обновить все записи в поле S нарастающим итогом по возростанию даты в поле D пределах одинаковых значений в поле G Таблица G - varchar D - datetime M - money S - money ... |
|||
:
Нравится:
Не нравится:
|
|||
20.06.2013, 12:07 |
|
Можно ли существенно оптимизировать данную процедуру.
|
|||
---|---|---|---|
#18+
Glory, Разрешите и мне вставить свои 5 копеек, раз с меня началось. Действительно. Все зависит от задачи. Моя задача успешно решилась благодаря просмотру плана исполнения. Признаю, сглупил, не разобрался, зря потревожил народ. Оказалось виноват маленький триггерок, который логирует записи. В него затесался забытый запрос об обновлении одной ячейки. И стоимость то всего была 0,51%. Однако на большом количестве - вот и результат. Просто в голову не пришло посмотреть. Лог и лог. Что там можно исправить. Теперь мой кривой код на курсоре работает одну секунду. Клиент кнопку нажал - получил результат. Просто отлично. В данном случае наглядность и простота кода лучше. Я, не имея специального образования, решил поставленную задачу с хорошим результатом. Конечно нужно обязательно прочесть то, что Вы все мне любезно порекомендовали, и это будет обязательно сделано, т.к. много еще всего нужно исправлять. И учиться нужно. Ну пока вот так, на пробах и ошибках. Спасибо. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.06.2013, 12:10 |
|
Можно ли существенно оптимизировать данную процедуру.
|
|||
---|---|---|---|
#18+
Cammomileну вот же DirksDRdimon71, Нет информации о размерах таблицы. Но 20 сек даже для миллиона записей много. Вряд ли в справочние товаров у Вас больше. Проверьте наличие и использование индексов. Использование курсоров не так уж критически сказывается на быстродействии. Зато намного наглядней алгоритм(скрипт). Ааа... Ну использование курсоров на самом деле может очень существенно сказываться на производительности. Причем, как ни странно, в обе стороны. На счет наглядности я бы тоже поспорил — запросы читать проще, сразу все ясно, и объективно это проще, декларативная логика запроса описывает, что надо сделать, а не как и что надо сделать, так что можно сказать в двп раза проще понимать. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.06.2013, 12:24 |
|
Можно ли существенно оптимизировать данную процедуру.
|
|||
---|---|---|---|
#18+
CammomileВсе таки я бы хотел видеть конкретный пример. А не "любую" задачу. За 7 лет практики не припомню таких "любых" задач где курсор был бы быстрее. Задачи где без курсора просто никак - да, много. А мы же говорим за _быстрее_, правда? Они действительно редки в бд. Но я одну такую знаю — партионое списание товаров по FIFO или LIFO. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.06.2013, 12:28 |
|
Можно ли существенно оптимизировать данную процедуру.
|
|||
---|---|---|---|
#18+
В данном случае наглядность и простота кода лучше. Извини, наглядностью в твоем коде даже нее пахнет. Я, не имея специального образования, решил поставленную задачу с хорошим результатом. Чтобы писать на SQL особенно -то много спец. Образования и не надо, Надо только знать, что надо писать запросы везде, где только возможно, использовать индексы и выделять серверу память под кэш. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.06.2013, 12:34 |
|
Можно ли существенно оптимизировать данную процедуру.
|
|||
---|---|---|---|
#18+
dimon71В данном случае наглядность и простота кода лучше. Я, не имея специального образования, решил поставленную задачу с хорошим результатом.Конечно, нагладность и простота очень важны, и то, что задача решена - замечательно, но конкретно решение вашей задачи нагляднее и проще читается без курсоров. Нужно комментарии на русском в процедуре записать на языке SQL в одном запросе, только и всего. Просто для вас SQL не основной язык, вы к нему не привыкли, не чувствуете его. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.06.2013, 12:37 |
|
Можно ли существенно оптимизировать данную процедуру.
|
|||
---|---|---|---|
#18+
MasterZivCammomileВсе таки я бы хотел видеть конкретный пример. А не "любую" задачу. За 7 лет практики не припомню таких "любых" задач где курсор был бы быстрее. Задачи где без курсора просто никак - да, много. А мы же говорим за _быстрее_, правда? Они действительно редки в бд. Но я одну такую знаю — партионое списание товаров по FIFO или LIFO. это частный случай нарастающего итога - той самой класической и одной единственной задачи (хотя и весьма распространенной) где курсор лучше. Умрет с появлением инструкции: update .... from ... order by ... ... |
|||
:
Нравится:
Не нравится:
|
|||
20.06.2013, 12:40 |
|
Можно ли существенно оптимизировать данную процедуру.
|
|||
---|---|---|---|
#18+
GloryCammomileВсе таки я бы хотел видеть конкретный пример. А не "любую" задачу. Да легко Обновить все записи в поле S нарастающим итогом по возростанию даты в поле D пределах одинаковых значений в поле G Таблица G - varchar D - datetime M - money S - money 1: А в какой версии сервера, раз у пошел разговор? Если 2012 то быстрее будет с окнами. 2: Если 2005 , то " на глазок" есть "необычный апдейт", и мне пока кажется что он быстрее. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.06.2013, 12:41 |
|
Можно ли существенно оптимизировать данную процедуру.
|
|||
---|---|---|---|
#18+
Cammomile2: Если 2005 , то " на глазок" есть "необычный апдейт", и мне пока кажется что он быстрее. Он был еще в 2000. Только он не гарантирует порядок. А именно про задачи завязанные на порядок обработки записей я и говорил. Cammomile1: А в какой версии сервера, раз у пошел разговор? Если 2012 то быстрее будет с окнами. Вы уже проверили это ? ... |
|||
:
Нравится:
Не нравится:
|
|||
20.06.2013, 12:43 |
|
Можно ли существенно оптимизировать данную процедуру.
|
|||
---|---|---|---|
#18+
Я спросил у людей кот. попробовали, у меня 2012 нет =) Выигышь, говорят, в разы. "Только он не гарантирует порядок." Это серьезный аргумент. Ну тогда вариант с курсором перезжает из категории "быстрее аналогичного апдейта" в категорию "единственное приемлимое решение", что тоже вне темы нашего обсуждения. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.06.2013, 13:07 |
|
Можно ли существенно оптимизировать данную процедуру.
|
|||
---|---|---|---|
#18+
CammomileЯ спросил у людей кот. попробовали, у меня 2012 нет =) Выигышь, говорят, в разы. Ага. Слышал в вашего Карузо. Мне Рабинович напел CammomileТолько он не гарантирует порядок." Это серьезный аргумент. Ну тогда вариант с курсором перезжает из категории "быстрее аналогичного апдейта" в категорию "единственное приемлимое решение", что тоже вне темы нашего обсуждения. курсор не единственный способ получения такого нарастающего итога. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.06.2013, 13:10 |
|
Можно ли существенно оптимизировать данную процедуру.
|
|||
---|---|---|---|
#18+
Ну там весьма авторитетный рабинович напел. Так, вы сказали что есть случаи когда курсор быстрее аналогичного апдейта/селекта/ инсерта. В вашем примере НЕТ аналогичного апдейта/селекта/инсерта. А раз так, о чем разговор? ... |
|||
:
Нравится:
Не нравится:
|
|||
20.06.2013, 13:23 |
|
Можно ли существенно оптимизировать данную процедуру.
|
|||
---|---|---|---|
#18+
CammomileВ вашем примере НЕТ аналогичного апдейта/селекта/инсерта. А раз так, о чем разговор? Что значит НЕаналогичный ? update from join он и африке update Или вы знаете другие команды обновления ? ... |
|||
:
Нравится:
Не нравится:
|
|||
20.06.2013, 13:25 |
|
Можно ли существенно оптимизировать данную процедуру.
|
|||
---|---|---|---|
#18+
Код: sql 1.
аналогичный курсор который никак не может быть быстрее (типа того что делает автор топика) Код: sql 1. 2. 3. 4. 5. 6. 7.
... |
|||
:
Нравится:
Не нравится:
|
|||
20.06.2013, 13:37 |
|
Можно ли существенно оптимизировать данную процедуру.
|
|||
---|---|---|---|
#18+
Cammomile аналогичный курсор который никак не может быть быстрее (типа того что делает автор топик Смешной вы. Вы под аналогией понимаете давайте выполнять массовый апдейт в цикле по одной записи ? Вы заявили, что все курсоры обязательно должны быть переписаны в запросы. Даже у автора темы идут какие-то рассчеты и проверки. И вы даже не знаете, можно ли их осуществить в вашем update t set f = 1 where d in (1,2,3) ... |
|||
:
Нравится:
Не нравится:
|
|||
20.06.2013, 13:43 |
|
Можно ли существенно оптимизировать данную процедуру.
|
|||
---|---|---|---|
#18+
dimon71, можно оптимизировать, надо избавиться от курсора ... |
|||
:
Нравится:
Не нравится:
|
|||
20.06.2013, 14:26 |
|
Можно ли существенно оптимизировать данную процедуру.
|
|||
---|---|---|---|
#18+
... |
|||
:
Нравится:
Не нравится:
|
|||
20.06.2013, 14:26 |
|
Можно ли существенно оптимизировать данную процедуру.
|
|||
---|---|---|---|
#18+
О годная аналитика. Сейчас почитаем. Кстати, касаемо "стремного апдейта" Мне кажется, что "не гарантирует порядка" больше спекуляция 1 - нет документированных случаев когда этот метод подвел бы 2 - сама конструкция подразумевает, что ее надо использовать именно для нарастающего итога, а эскуль сервер все-таки не идеоты писали 3 - конструкция успешно пережила все редакции сервера начиная с 2000 и все многочисленные багфиксы и апдейты По мне так вполне надежно, не ? ... |
|||
:
Нравится:
Не нравится:
|
|||
20.06.2013, 14:32 |
|
Можно ли существенно оптимизировать данную процедуру.
|
|||
---|---|---|---|
#18+
CammomileМне кажется, что "не гарантирует порядка" больше спекуляция 1 - нет документированных случаев когда этот метод подвел бы У вас есть документированный способ указания порядка обработки записей ? Cammomile2 - сама конструкция подразумевает, что ее надо использовать именно для нарастающего итога, а эскуль сервер все-таки не идеоты писали Это вы цитируете документацию ? Cammomile3 - конструкция успешно пережила все редакции сервера начиная с 2000 и все многочисленные багфиксы и апдейты Разговор не про саму конструкцию, про гарантированный порядок. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.06.2013, 14:56 |
|
Можно ли существенно оптимизировать данную процедуру.
|
|||
---|---|---|---|
#18+
CammomileО годная аналитика. Сейчас почитаем. Кстати, касаемо "стремного апдейта" Мне кажется, что "не гарантирует порядка" больше спекуляция 1 - нет документированных случаев когда этот метод подвел бы 2 - сама конструкция подразумевает, что ее надо использовать именно для нарастающего итога, а эскуль сервер все-таки не идеоты писали 3 - конструкция успешно пережила все редакции сервера начиная с 2000 и все многочисленные багфиксы и апдейты По мне так вполне надежно, не ?такая логика для ответственных применений не годится. разработчики сервера вам ничего по поводу этой конструкции не обещают => слово "надежно" тут вообще не применимо. о чем и говорится в статье, кстати I’ll re-state that I don’t believe this approach is safe for production, regardless of the testimony you’ll hear from people indicating that it “never fails.” Unless behavior is documented and guaranteed, I try to stay away from assumptions based on observed behavior. You never know when some change to the optimizer’s decision path (based on a statistics change, data change, service pack, trace flag, query hint, what have you) will drastically alter the plan and potentially lead to a different order ... |
|||
:
Нравится:
Не нравится:
|
|||
20.06.2013, 15:05 |
|
Можно ли существенно оптимизировать данную процедуру.
|
|||
---|---|---|---|
#18+
CammomileМне кажется, что "не гарантирует порядка" больше спекуляция Вопрос на злобу дня - Просмотр кластеризованного индекса - Часть 1 Вопрос на злобу дня - Просмотр кластеризованного индекса - Часть 2 Вопрос на злобу дня - Просмотр кластеризованного индекса - Часть 3 ... |
|||
:
Нравится:
Не нравится:
|
|||
20.06.2013, 15:37 |
|
Можно ли существенно оптимизировать данную процедуру.
|
|||
---|---|---|---|
#18+
Раз пошла такая пьянка- режь последний огурец ! ... |
|||
:
Нравится:
Не нравится:
|
|||
20.06.2013, 15:38 |
|
Можно ли существенно оптимизировать данную процедуру.
|
|||
---|---|---|---|
#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/moderation_log.php?user_name=%D0%90%D0%BD%D0%B4%D1%80%D0%B5%D0%B9%D0%9A%D0%BE%D0%BD%D1%81%D1%82%D0%B0%D0%BD%D1%82%D0%B8%D0%BD%D0%BE%D0%B2%D0%B8%D1%87]: |
0ms |
get settings: |
9ms |
get forum list: |
14ms |
get settings: |
10ms |
get forum list: |
13ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
185ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
84ms |
get tp. blocked users: |
1ms |
others: | 440ms |
total: | 778ms |
0 / 0 |