11.3. Ограничения на подзапросы

11.3. Ограничения на подзапросы

Известная ошибка, которая будет фиксирована позже: если Вы сравниваете значение NULL с подзапросом, использующим ALL, ANY или SOME, и подзапрос возвращают пустой результат, сравнение может быть оценено к ненормативному результату NULL, а не к TRUE или FALSE.

Внешняя инструкция подзапроса может быть любой из SELECT, INSERT, UPDATE, DELETE, SET или DO.

Оптимизация подзапроса для IN не как эффективна, как для оператора = или для конструкции IN(value_list).

Типичный случай для недостаточной эффективности подзапроса IN: когда подзапрос возвращает маленькое число строк, но внешний запрос возвращает большое количество строк, которые нужно сравнить с результатом подзапроса.

Проблема состоит в том, что для инструкции, которая использует в подзапросе IN, оптимизатор перезаписывает это как соотнесенный подзапрос. Рассмотрите следующую инструкцию, которая использует несоотнесенный подзапрос:

SELECT … FROM t1 WHERE t1.a IN (SELECT b FROM t2);

Оптимизатор переписывает инструкцию к соотнесенному подзапросу:

SELECT … FROM t1 WHERE EXISTS (SELECT 1 FROM t2 WHERE t2.b = t1.a);

Если внутренние и внешние запросы возвращают M и N строк соответственно, время выполнения становится порядка O(M^N), а не O(M+N), как это было бы для несоотнесенного подзапроса.

Подзапрос IN может быть намного медленнее, чем запрос, написанный с использованием конструкции IN(value_list), которая вносит в список те же самые значения, которые возвратил бы подзапрос.

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

DELETE FROM t WHERE … (SELECT … FROM t …);

UPDATE t … WHERE col = (SELECT … FROM t …);

{INSERT|REPLACE} INTO t (SELECT … FROM t …);

Исключительная ситуация: предшествующее запрещение не применяется, если Вы используете подзапрос для изменяемой таблицы в предложении FROM. Пример:

UPDATE t … WHERE col = (SELECT (SELECT … FROM t…) AS _t …);

Здесь запрещение не применяется, потому что результат от подзапроса в предложении FROM сохранен как временная таблица, так что релевантные строки в t уже были выбраны ко времени модификации t.

Операции сравнения строк обеспечиваются пока только частично:

Для expr IN (subquery), expr может быть n-кортеж (определенный через синтаксис конструктора строки) и подзапрос может возвращать строки n-кортежей.

Для expr op {ALL|ANY|SOME} (подзапрос), expr должен быть скалярным значением, и подзапрос должен быть подзапросом столбца, это не может возвращать строки с многими столбцами.

Другими словами, для подзапроса, который возвращает строки n-кортежей, это обеспечивается:

(val_1, …, val_n) IN

(subquery)

Но это не обеспечивается:

(val_1, …, val_n)

op {ALL|ANY|SOME} (subquery)

Причина для обеспечения сравнений строки для IN, но не для других: IN выполнен, перезаписывая это как последовательность сравнений = и операций AND. Этот подход не может использоваться для ALL, ANY или SOME.

Конструкторы строк не оптимизированы хорошо. Следующие два выражения эквивалентны, но только второе может быть оптимизировано:

(col1, col2, …) = (val1, val2, …)

col1 = val1 AND col2 = val2 AND …

Подзапросы в предложении FROM не могут быть соотнесены подзапросам. Они осуществлены (выполнены, чтобы произвести набор результатов) перед оценкой внешнего запроса, так что они не могут быть оценены на строку внешнего запроса.

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

Исключительная ситуация происходит для случая, где подзапрос IN может быть переписан как объединение SELECT DISTINCT. Пример:

SELECT col FROM t1 WHERE id_col IN (SELECT id_col2 FROM t2 WHERE

condition);

Эта инструкция может быть переписана следующим образом:

SELECT DISTINCT col FROM t1, t2 WHERE t1.id_col = t2.id_col AND

condition;

Но в этом случае объединение требует операции DISTINCT, и не более эффективно, чем подзапрос.

Возможная будущая оптимизация: MySQL не переписывает порядок объединения для оценки подзапроса. В некоторых случаях подзапрос мог бы быть выполнен более эффективно, если MySQL переписал это как объединение. Это дало бы оптимизатору возможность, чтобы выбрать между большим количеством планов выполнения. Например, это могло бы решать, читать ли одну таблицу или другую первой:

SELECT a FROM outer_table AS ot

WHERE a IN (SELECT a FROM inner_table AS

it WHERE ot.b = it.b);

Для этого запроса MySQL всегда просматривает сначала outer_table, а затем выполняет подзапрос на inner_table для каждой строки. Если outer_table имеет много строк, и inner_table имеет немного строк, запрос, вероятно, не будет работать с такой скоростью как могло бы быть.

Предшествующий запрос мог бы быть переписан подобно этому:

SELECT a FROM outer_table AS ot, inner_table AS it

WHERE ot.a = it.a AND

ot.b = it.b;

В этом случае мы можем просматривать маленькую таблицу (inner_table) и искать строки в outer_table, что будет быстро, если имеется индекс на (ot.a,ot.b).

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

Возможная будущая оптимизация: подзапрос в предложении FROM оценен, осуществляя результат во временную таблицу, и эта таблица не использует индексы. Это не позволяет использование индексов по сравнению с другими таблицами в запросе, хотя это могло бы быть полезно.

Возможная будущая оптимизация: если подзапрос в предложении FROM походит на просмотр, к которому может применяться объединяющийся алгоритм, переписать запрос и применить объединяющийся алгоритм так, чтобы индексы могли использоваться. Следующая инструкция содержит такой подзапрос:

SELECT * FROM (SELECT * FROM t1 WHERE t1.t1_col) AS _t1, t2 WHERE t2.t2_col;

Инструкция может быть переписана как объединение подобно этому:

SELECT * FROM t1, t2 WHERE t1.t1_col AND t2.t2_col;

Этот тип перезаписи обеспечил бы две выгоды:

Это избегает использования временной таблицы, для которой никакие индексы не могут использоваться. В переписанном запросе оптимизатор может использовать индексы на t1.

Это дает оптимизатору большее количество свободы выбрать между различными планами выполнения. Например, перезапись запроса как объединения позволяет оптимизатору использовать сначала t1 или t2.

Возможная будущая оптимизация: для IN, = ANY, <> ANY, = ALL и <> ALL с не соотнесенными подзапросами использовать в оперативной памяти хэш для результата или временную таблицу с индексом для больших результатов. Пример:

SELECT a FROM big_table AS bt WHERE non_key_field IN

(SELECT non_key_field FROM table WHERE

condition)

В этом случае мы могли бы создавать временную таблицу:

CREATE TABLE t (key (non_key_field))

(SELECT non_key_field FROM table WHERE

condition)

Затем для каждой строки в big_table сделайте поисковую таблицу ключа в t, основываясь на bt.non_key_field.

Поделитесь на страничке

Следующая глава >

Похожие главы из других книг

1.5 Ограничения

Из книги Процессы жизненного цикла программных средств автора Автор неизвестен


Ограничения

Из книги Симуляция частичной специализации автора Кузнецов Павел

Ограничения Приведенная техника симуляции частичной специализации обладает некоторыми ограничениями по сравнению с «настоящей» частичной специализацией шаблонов классов.Одним из наиболее заметных ограничений является то, что дискриминирующие функции,


Ограничения

Из книги Управление исходными текстами. Часть 1. Краткое руководство по CVS автора Рыженков Илья

Ограничения CVS не является заменой управлению проектами, это всего лишь один из инструментов команды. Также этот инструмент сам по себе не содержит механизмов автоматический сборки (build system), регрессионного тестирования (regression testing), взаимодействия разработчиков (collaboration)


Подзапросы

Из книги Обработка баз данных на Visual Basic®.NET автора Мак-Манус Джеффри П

Подзапросы Подзапрос (subquery) — это запрос, результат которого служит критерием для другого запроса. Подзапросы занимают место обычного выражения WHERE. Поскольку результат, сгенерированный подзапросом, используется вместо выражения, подзапрос может возвращать только


2.4.6. Ограничения

Из книги MySQL: руководство профессионала автора Паутов Алексей В

2.4.6. Ограничения Имеется ряд ограничений в alpha-версии Falcon. В дальнейшем они постепенно будут сниматься:Не работает SELECT FOR UPDATE. Для Alpha-версии максимальная длина ключа ограничена 1100 байтами. Уровни изоляции Serializable не обеспечиваются. Конфигурация времени ожидания для


2.8.2. Ограничения CSV

Из книги Разработка приложений в среде Linux. Второе издание автора Джонсон Майкл К.

2.8.2. Ограничения CSV Важно: тип памяти CSV не поддерживает индексацию.Выделение разделов не обеспечивается для таблиц, использующих CSV. Начиная с MySQL 5.1.12, больше не возможно создать разбитую на разделы таблицу CSV (Глюк


7.5.4. Ограничения

Из книги Firebird РУКОВОДСТВО РАЗРАБОТЧИКА БАЗ ДАННЫХ автора Борри Хелен

7.5.4. Ограничения Несмотря на то что Electric Fence выполняет неплохую работу по обнаружению переполнения буферов, выделенных malloc(), он не помогает отслеживать проблемы ни с глобальными, ни с локальными данными. Electric Fence также не обнаруживает утечки памяти, потому решать эту


Ограничения

Из книги Понимание SQL автора Грубер Мартин

Ограничения На языке реляционных баз данных любое условие, налагаемое на формат, диапазон значений, содержание или зависимости структуры данных, называется ограничением (constraint). Firebird предоставляет несколько способов для реализации ограничений, включая как формальные,


Ограничения

Из книги автора

Ограничения Firebird допускает до 256 определенных пользователем индексов на одну таблицу в версии 1.5 и выше, и 64 в более ранних релизах. Однако это теоретические ограничения, которые могут быть скорректированы за счет размера страницы и фактического размера на диске данных


Ограничения

Из книги автора

Ограничения Никакой пользователь не может удалить индекс, кроме его создателя, пользователя SYSDBA или (в POSIX) пользователя с привилегиями root.Определенные системой индексы, созданные автоматически для столбцов, определенных в ограничениях уникального, первичного или


Подзапросы

Из книги автора

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


Подзапросы

Из книги автора

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


Реентерабельные подзапросы

Из книги автора

Реентерабельные подзапросы Запрос может использовать реентерабельный подзапрос для задания условия поиска в той же таблице. Использование алиасов таблиц является обязательным. В следующем примере оператор выполняет подзапрос для поиска в главной таблице даты самой


Ограничения

Из книги автора

Ограничения При удалении процедуры существуют ограничения.* Только пользователь SYSDBA и владелец процедуры могут ее удалять.* Процедура, находящаяся в использовании в любой другой транзакции, не может быть удалена. Это является особой проблемой в системах, где процедуры


Глава 11. СООТНЕСЕННЫЕ ПОДЗАПРОСЫ

Из книги автора

Глава 11. СООТНЕСЕННЫЕ ПОДЗАПРОСЫ В ЭТОЙ ГЛАВЕ, МЫ ПРЕДСТАВИМ ВАС ТИПУ подзапроса о котором мы не говорили в Главе 10 - посвященной соотнесенному подзапросу. Вы узнаете как использовать соотнесенные подзапросы в предложениях запросов WHERE и HAVING. Сходства и различия между