Повторяющиеся SQL-запросы

Что считается лучшей практикой для выполнения повторяющихся запросов SQL? Насколько я понимаю, нужно использовать параметризованный запрос и превратить его в подготовленный оператор при первом выполнении. Что, если этот запрос должен выполняться несколькими потоками? Нужно ли будет создавать подготовленный оператор для каждого типа запроса для каждого потока? Или в настоящее время синтаксический анализ операторов SQL настолько эффективен, что подготовленные операторы больше не нужны?


person Tony the Pony    schedule 04.08.2009    source источник


Ответы (2)


Хороший вопрос - ответил по одному биту за раз.

  • Что считается лучшей практикой для выполнения повторяющихся запросов SQL?

Если запрос будет повторяться независимо от различий в параметрах, используйте подготовленные операторы.

  • Насколько я понимаю, нужно использовать параметризованный запрос и превратить его в подготовленный оператор при первом выполнении.

Это мое мнение о том, что нужно делать. Обычно советовали готовить все запросы при запуске программы. На мой взгляд, это всегда было чепухой; он перегружает сервер запросами, многие из которых не будут использоваться ни в одном конкретном запуске, что приводит к трате памяти как в клиенте, так и в СУБД. Всегда было наиболее разумно готовить отчеты по требованию; когда это было впервые необходимо, и только тогда, когда это было необходимо. Я бы допустил исключение для операторов, которые будут выполняться «всегда», но мне нужно было бы убедиться, что «всегда» было действительно близко к 100% времени.

  • Что, если этот запрос должен выполняться несколькими потоками? Нужно ли будет создавать подготовленный оператор для каждого типа запроса для каждого потока?

Это зависит от того, как различные потоки взаимодействуют с СУБД. В СУБД, с которой я знаком, если есть одно соединение, которое разделяют все потоки, вам нужно подготовить его только один раз для одного соединения. Если у каждого потока есть свое отдельное соединение, то вам нужно подготовить оператор для каждого потока отдельно.

  • Или в настоящее время синтаксический анализ операторов SQL настолько эффективен, что подготовленные операторы больше не нужны?

Машины быстрые - да. А для неповторяющихся операторов не стоит беспокоиться о накладных расходах. Но если вы собираетесь выполнить запрос несколько миллионов раз, то затраты на его подготовку несколько миллионов раз начинают складываться. Кроме того, машины сервера баз данных обычно являются общими ресурсами, но запрос, скорее всего, будет подготовлен отдельно для каждого пользователя, поэтому, если у вас есть несколько пользователей, забивающих систему повторяющимися запросами, которые отбрасываются, сервер будет слишком занят подготовкой запросов, чтобы выполнять какие-либо запросы. из них быстро.

Итак, мой ответ: «Нет». Подготовленные операторы по-прежнему полезны, когда запросы будут повторяться достаточно часто, где «достаточно часто», вероятно, не так уж часто. Сотни раз - используйте подготовленные операторы. Десятки раз - возможно, используйте подготовленные операторы. Меньше этого - возможно, не используйте подготовленные операторы.

person Jonathan Leffler    schedule 04.08.2009
comment
Учитывая, что подготовленный оператор часто использует память на сервере, а также на клиенте. Я бы посмотрел на % рабочей нагрузки, которую составляет каждый запрос, а также на то, сколько раз каждый запрос повторялся. Я бы посмотрел на сотни использований, а не на десятки, прежде чем усложнять код с использованием подготовленных операторов. - person Ian Ringrose; 05.08.2009

Ну, вы не упомянули среду, которую используете, но в целом вы также можете рассмотреть хранимые процедуры (если ваш механизм БД поддерживает это). Его преимущество заключается в создании дополнительного уровня абстракции в самой базе данных, что делает точную схему базы данных менее актуальной для клиентских приложений.

В большинстве случаев рекомендуется использовать параметризованные запросы не только ради производительности, но и для защиты от SQL-инъекций и предотвращения проблем с преобразованием типов данных (локализация даты и времени).

person mmx    schedule 04.08.2009