|
|
|
Формирование запроса
|
|||
|---|---|---|---|
|
#18+
С клиентского приложения формируется запрос Код: plaintext Код: plaintext 1. Насколько будет критичным не добавлять динамически а формировать запрос так: Код: plaintext С уважением, Naf ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.04.2009, 09:40 |
|
||
|
Формирование запроса
|
|||
|---|---|---|---|
|
#18+
Naf, Я бы использовал обычную ХП без всякой динамики, имхо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.04.2009, 11:22 |
|
||
|
Формирование запроса
|
|||
|---|---|---|---|
|
#18+
Senya_LNaf, Я бы использовал обычную ХП без всякой динамики, имхо. на каждый запрос писать ХП? потом в ХП все равно передавать 2 параметра: значение отбора и флаг установленности отбора ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.04.2009, 11:29 |
|
||
|
Формирование запроса
|
|||
|---|---|---|---|
|
#18+
Nafна каждый запрос писать ХП?Это вопрос предпочтений/возможностей СУБД. Если используете MSSQL, то состав столбцов в выходном рекордсете может быть переменным, а вот в Firebird такое не прокатит.Nafпотом в ХП все равно передавать 2 параметра: значение отбора и флаг установленности отбораИ в чем тут проблема? Передавайте. ЗЫ. Разок столкнулся с такой ситуацией. При выводе реестра используется флаг, означающий применять или не применять фильтр. Получал странные тормоза. В итоге просто разбил на два запроса с IF ... ELSE. Это я к тому, что условие OR, похоже, СУБД не всегда "переваривают". :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.04.2009, 12:38 |
|
||
|
Формирование запроса
|
|||
|---|---|---|---|
|
#18+
В различных СУБД можно сделать по-разному универсальность запроса с фильтром/без, например: (field = :param or :param is null). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.04.2009, 12:25 |
|
||
|
Формирование запроса
|
|||
|---|---|---|---|
|
#18+
MegabyteВ различных СУБД можно сделать по-разному универсальность запроса с фильтром/без, например: (field = :param or :param is null). это отнюдь не быстрый вариант в любой СУБД, как только количество фильтров увеличится... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.04.2009, 14:15 |
|
||
|
Формирование запроса
|
|||
|---|---|---|---|
|
#18+
АнатоЛойMegabyteВ различных СУБД можно сделать по-разному универсальность запроса с фильтром/без, например: (field = :param or :param is null). это отнюдь не быстрый вариант в любой СУБД, как только количество фильтров увеличится... Тестов, канеш, не проводил, но неужели медленнее динамикСкуля будет? :) Проверка на Null параметра разве медленнее динамического формирования запроса? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.04.2009, 12:38 |
|
||
|
Формирование запроса
|
|||
|---|---|---|---|
|
#18+
MegabyteАнатоЛойMegabyteВ различных СУБД можно сделать по-разному универсальность запроса с фильтром/без, например: (field = :param or :param is null). это отнюдь не быстрый вариант в любой СУБД, как только количество фильтров увеличится... Тестов, канеш, не проводил, но неужели медленнее динамикСкуля будет? :) Проверка на Null параметра разве медленнее динамического формирования запроса? Попробуйте на Вашей любимой СУБД с 5-кой таких условий (field1 = :param1 or :param1 is null) and (field2 = :param2 or :param2 is null) and (field3 = :param3 or :param3 is null) and (field4 = :param4 or :param4 is null) and (field5 = :param5 or :param5 is null) добавьте индексов на эти поля в любых понравившихся комбинациях и покажите плна запроса. Потом мысленно или реально добавьте в таблицу сотню лимонов записей - и меееедленно проникайтесь... При динамическом формировании если задан один параметр, то Вы получите только одно условие типа (field4 = :param4 or :param4 is null) с адекватным планом по нему... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.04.2009, 14:50 |
|
||
|
Формирование запроса
|
|||
|---|---|---|---|
|
#18+
Тут есть еще другой аспект - повторное использование запроса (на примере Oracle). Если все параметры сразу присутствуют в запросе, то запрос будет использован повторно, при динамике - каждый раз разбор и построение плана выполнения (hard parse). Поэтому если время выборки значительно превышает время разбора (т.е. когда записей дофига) - это одно, если нет - это другое... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.04.2009, 15:01 |
|
||
|
Формирование запроса
|
|||
|---|---|---|---|
|
#18+
АнатоЛой(field1 = :param1 or :param1 is null) and (field2 = :param2 or :param2 is null) and (field3 = :param3 or :param3 is null) and (field4 = :param4 or :param4 is null) and (field5 = :param5 or :param5 is null) добавьте индексов на эти поля в любых понравившихся комбинациях и покажите плна запроса. Потом мысленно или реально добавьте в таблицу сотню лимонов записей - и меееедленно проникайтесь... При динамическом формировании если задан один параметр, то Вы получите только одно условие типа (field4 = :param4 or :param4 is null) с адекватным планом по нему... От оптимизатора СУБД зависит. Есть оптимизаторы, которые проводят несколько ступеней оптимизации запроса, в том числе выкидывая с него не используемые таблицы, условия и т.д. Соответственно и план запросов у них будет простым и эффективным. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.04.2009, 15:06 |
|
||
|
Формирование запроса
|
|||
|---|---|---|---|
|
#18+
ASCRUSАнатоЛой(field1 = :param1 or :param1 is null) ... (field5 = :param5 or :param5 is null) От оптимизатора СУБД зависит. Есть оптимизаторы, которые проводят несколько ступеней оптимизации запроса, в том числе выкидывая с него не используемые таблицы, условия и т.д. Соответственно и план запросов у них будет простым и эффективным. Предлагаю не полениться и привести здесь планы запросов: каждый от "своей" СУБД :) Доберусь завтра до Informix - приведу из него. Очень хочется посмотреть, что же получится на разных СУБД. Тестовый пример (модифицируйте под синтаксис своей СУБД) Надеюсь синтаксис Informix SQL/SPL достаточно понятный Код: plaintext 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. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.04.2009, 23:58 |
|
||
|
Формирование запроса
|
|||
|---|---|---|---|
|
#18+
tru55Тут есть еще другой аспект - повторное использование запроса (на примере Oracle). Если все параметры сразу присутствуют в запросе, то запрос будет использован повторно, при динамике - каждый раз разбор и построение плана выполнения (hard parse). Поэтому если время выборки значительно превышает время разбора (т.е. когда записей дофига) - это одно, если нет - это другое... Я бы вёл речь не о динамическом формировании запроса с константами-фильтрами, а о "ручном" отбрасывании заведомо правдивых условий, а условия формировать таки параметризоваными. При N параметрах-фильтрах получаем аж N! (факториал) разных по тексту запросов... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.04.2009, 00:02 |
|
||
|
Формирование запроса
|
|||
|---|---|---|---|
|
#18+
АнатоЛойПредлагаю не полениться и привести здесь планы запросов: каждый от "своей" СУБД :) Доберусь завтра до Informix - приведу из него. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. Вот так :( У кого лучше? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.04.2009, 13:26 |
|
||
|
Формирование запроса
|
|||
|---|---|---|---|
|
#18+
это из-за prepare запроса, то есть из-за вызова его внутри функции, он там подготавливается при компиляции функции и больше не изменяется - поэтому оптимизатор не может выкинуть условия, он же не знает заранее какие параметры Вы ему передадите в функцию. если же запрос выполнять напрямую, без функции, то имхо должен и у Вас догадаться, например: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. -- „Истина — это вовсе не то, что можно убедительно доказать, это то, что делает всё проще и понятнее“ — Антуан де Сент-Экзюпери ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.04.2009, 16:32 |
|
||
|
Формирование запроса
|
|||
|---|---|---|---|
|
#18+
Ёш, проблема не в SP, а в параметризации запроса. Вы ведь показываете вариант непараметризованного запроса и заданный фильтр уже вписан в текст константой? Если да, смотрите ту же проблему кеша запросов, про которую писал tru55 (а также писал пресловутый "Ask" Tom - имхо, не мегаэксперт, но по крайней мере звезда среди экспертов - и профессионалу нужно точно представлять, почему он согласен либо не согласен с мнениями таких товарищей). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.04.2009, 17:32 |
|
||
|
Формирование запроса
|
|||
|---|---|---|---|
|
#18+
Sybase ASA 10. План при всех пустых параметрах выдает table scan, что правильно. Код: plaintext 1. 2. 3. 4. Устанавливаем p_field1=1. План снова выдает table scan, что тоже правильно (это поле имеет значение 1 для всех записей). Код: plaintext 1. 2. 3. 4. 5. Устанавливаем p_field1=1 и p_field2=32. Естественно оптимизатор взял индекс по второму полю, так как по первому значение присутствует во всех записях и условие field1 = 1 будет вынесено в постфильтр. Код: plaintext 1. 2. 3. 4. 5. 6. Тоже самое будет при установке или сбросе значений различных параметров - оптимизатор будет сначала переделывать запрос, выбрасывая не нужные его части (условия и соединения), далее по статистике, индексам, кол-ву свободной памяти, информации по текущему состоянию кеша и прочему, решать, какой план запроса будет оптимален. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.05.2009, 11:37 |
|
||
|
Формирование запроса
|
|||
|---|---|---|---|
|
#18+
Ёшэто из-за prepare запроса, то есть из-за вызова его внутри функции, он там подготавливается при компиляции функции и больше не изменяется - поэтому оптимизатор не может выкинуть условия, он же не знает заранее какие параметры Вы ему передадите в функцию. Опять же от сервера зависит. В ASA к примеру запросы при компиляции не привязываются к процедурам или функциям, а хранятся в специальном кэше планов запросов. Сами же хранимки и функции компилируются в байт-код, который так же кэшируется в памяти для его быстрого получения и выполнения при вызове, но в нем хранится не план запроса, а сам запрос, который при вызове и будет искаться в кэше запросов или же при отсутствии подходящего создан оптимизатором. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.05.2009, 11:46 |
|
||
|
Формирование запроса
|
|||
|---|---|---|---|
|
#18+
ASCRUSпри вызове и будет искаться в кэше запросов или же при отсутствии подходящего создан оптимизатором. Запрос оптимизируется до того, как известны параметры. Или ASA какие-то доп.приёмы применяет по оптимизации после того, как стали известны значения параметров? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.05.2009, 14:36 |
|
||
|
Формирование запроса
|
|||
|---|---|---|---|
|
#18+
АнатоЛойЗапрос оптимизируется до того, как известны параметры. Или ASA какие-то доп.приёмы применяет по оптимизации после того, как стали известны значения параметров? В ASA запрос оптимизируется перед непосредственным его выполнением, то есть после того, как известны параметры. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.05.2009, 16:27 |
|
||
|
Формирование запроса
|
|||
|---|---|---|---|
|
#18+
ASCRUSАнатоЛойЗапрос оптимизируется до того, как известны параметры. Или ASA какие-то доп.приёмы применяет по оптимизации после того, как стали известны значения параметров? В ASA запрос оптимизируется перед непосредственным его выполнением, то есть после того, как известны параметры. А в кеше какой запрос лежит: с именем параметра или со значением? Если с именем параметра, то типа экономим только на синтаксическом анализе - а планы выбираем на этапе выполнения, когда значения параметров известны. А когда варианты планов СТРОИМ: когда помещаем в кеш, когда известны значения параметров или ещё как? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.05.2009, 18:41 |
|
||
|
Формирование запроса
|
|||
|---|---|---|---|
|
#18+
АнатоЛойASCRUSАнатоЛойЗапрос оптимизируется до того, как известны параметры. Или ASA какие-то доп.приёмы применяет по оптимизации после того, как стали известны значения параметров? В ASA запрос оптимизируется перед непосредственным его выполнением, то есть после того, как известны параметры. А в кеше какой запрос лежит: с именем параметра или со значением? Если с именем параметра, то типа экономим только на синтаксическом анализе - а планы выбираем на этапе выполнения, когда значения параметров известны. А когда варианты планов СТРОИМ: когда помещаем в кеш, когда известны значения параметров или ещё как? Насчет того, что лежит в кэше ничего не скажу - это только сами разработчики ASA могут рассказать. Кэшем запросов можно управлять через опцию, в которой можно указать максимально допустимое кол-во кэшируемых запросов (или можно вообще его отключить). Проверить тоже не представляется возможным - у ASA оптимизатор слишком шустро генерит планы запросов даже при больших нагрузках (Watcom как никак, у них всегда компиляторы и виртуальные машины быстро бегали). Я лично могу предположить, что все таки в кэше хранится с именем параметра, так как планы запросов у ASA всегда актуальны на момент текущего состояния статистики таблиц, которая автопилотом обновляется на DML операторах. Иначе бы могли возникнуть ситуации, что оптимизатор использует не подходящий план запроса (когда например выполнили запрос, влили в таблицу существенный объем записей и снова выполнили тот же запрос). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.05.2009, 10:07 |
|
||
|
Формирование запроса
|
|||
|---|---|---|---|
|
#18+
Потому что по первому вашему посту непонятно, вы ХП делали, запрос с параметрами запускали или запрос с константами... Если не с параметрами, можете запустить запрос именно с параметрами, а не константами, и показать информацию о выборе плана? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.05.2009, 10:53 |
|
||
|
Формирование запроса
|
|||
|---|---|---|---|
|
#18+
АнатоЛойПотому что по первому вашему посту непонятно, вы ХП делали, запрос с параметрами запускали или запрос с константами... Если не с параметрами, можете запустить запрос именно с параметрами, а не константами, и показать информацию о выборе плана? Гм, как Вы и просили, я трансформировал Ваш скрипт в аналог Асашного и выдал план выполнения запросов с параметрами. Никаких констант там нет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.05.2009, 11:02 |
|
||
|
Формирование запроса
|
|||
|---|---|---|---|
|
#18+
ASCRUS, ок, пасибо. Остальное своё любопытство удовлетворять за ваш счёт уже неэтично :). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.05.2009, 11:29 |
|
||
|
Формирование запроса
|
|||
|---|---|---|---|
|
#18+
АнатоЛойASCRUS, ок, пасибо. Остальное своё любопытство удовлетворять за ваш счёт уже неэтично :). Да не за что :) Мне самому интересно разбираться в работе оптимизаторов различных серверов. У Sybase ASA кстати оптимизатор близок по логике работы к оптимизаторам прочих РСУБД и в 90% случаев он предсказуем, выбирает оптимальные планы запросов в зависимости от выставленных для сессии опций предпочтительной модели поведения (OLTP/OLAP, фоновое выполнение, уровень оптимизации, максимальное задействованное кол-во процессоров для параллельного выполнения частей запроса и т.д.). К примеру, у Sybase IQ, оптимизатор вообще своеобразный, начиная от своеобразных типов индексов и заканчивая тем, что в базе даже нет такого понятия, как статистика полей таблиц. Его работа для меня вообще загадка природы, хотя с точки зрения оптимизации планы запросов он генерит неплохие. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.05.2009, 12:17 |
|
||
|
|

start [/forum/topic.php?fid=32&msg=35973726&tid=1543266]: |
0ms |
get settings: |
10ms |
get forum list: |
13ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
188ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
45ms |
get tp. blocked users: |
1ms |
| others: | 241ms |
| total: | 514ms |

| 0 / 0 |
