Повторяющиеся запросы SQL - PullRequest
1 голос
/ 04 августа 2009

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

Ответы [ 2 ]

2 голосов
/ 05 августа 2009

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

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

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

  • Мое понимание состоит в том, чтобы использовать параметризованный запрос и превратить его в подготовленный оператор при первом выполнении.

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

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

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

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

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

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

2 голосов
/ 04 августа 2009

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

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

...