Что такое «беглый запрос»?

Question

В контексте SQL, что означает убегающий запрос ?

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

Answer 1

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

Answer 2

Это запрос, который запускается и никогда не возвращается (для некоторого значения "never").

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

Можно писать запросы SQL, выполнение которых занимает недели / годы.

Answer 3

Безудержные запросы имеют ряд характеристик - выберите некоторые из них:

• они производят гигантские наборы результатов
• они блокируют множество столов
• они приводят к большому количеству записей в журнал транзакций
• они потребляют огромные количества ввода / вывода и Ресурсы процессора

Во всех случаях они имеют тенденцию мешать другим пользователям выполнять какую-либо полезную работу.

Answer 4

Я применяю этот термин специально к запросу, который обычно вызывает случайное поведение со средой выполнения неожиданной сложности. Если вы ожидаете, что запрос займет O (n * m) (то есть одно соединение между двумя таблицами), и он займет O (n * n * m), то я бы назвал его убегающим, даже если n * n * m приемлемо маленький в данном случае. Чаще всего это воспринимается как запрос, ожидающий O (log (n) * log (m)), принимающий O (n * n * m * m), что оказывается неприемлемо сложным.

Answer 5

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

Возможные причины:

• Неиспользование индексированных столбцов
• Неправильное объединение таблиц (поэтому вы получаете хотя бы один кросс-продукт)
• Неверная статистика таблицы по использованным индексированным столбцам
• Множество сравнений строк или манипуляций

«Беглый» запрос может даже вернуться, просто потребуется слишком много или слишком много системных ресурсов, чтобы сделать его стоящим.

Answer 6

Когда запрос соединяет больше строк, чем необходимо, до точки превышения.

С Википедия : язык делает слишком простым создание декартового объединения (объединение всех возможных комбинаций), что приводит к наборам результатов "выбега", когда предложения WHERE вводятся неправильно Декартовы объединения настолько редко используются на практике, что может потребоваться явное ключевое слово CARTESIAN. В SQL 1992 было введено ключевое слово CROSS JOIN, которое позволяет пользователю ясно дать понять, что подразумевается декартово соединение, но сокращение "запятая-соединение" без предиката все еще является приемлемым синтаксисом.

Answer 7

Я считаю, что это означает, что вы выполняете и никогда не вернетесь. Например, выполнение оператора select, который никогда не вернется с результатами (или это займет очень много времени).

Answer 8

Просто упомянуть, что неудавшийся запрос может произойти, если задействован плохо написанный триггер. Триггеры должны быть способны обрабатывать вставки / обновления или деления с несколькими записями, и некоторые люди, как известно, делают это с помощью курсора, а не с помощью языка на основе множеств. Это может вызвать запрос на обновление большого количества записей. Недавно удалось сократить время запроса для большого набора обновляемых записей с 40 минут до 40 секунд, заменив один такой триггер.

Другие причины включают в себя случайные перекрестные объединения (исправленные с помощью отдельных), невыражаемые предложения where, использование подзапросов или используемых определенных функций, неправильное индексирование, статистика, которая не была обновлена, использование курсоров, недостаточное определение в объединении или где. И так далее.