Spec-Zone .ru
спецификации, руководства, описания, API
|
|
Spec-Zone .ru
спецификации, руководства, описания, API
|
С MySQL 5.6.3 оптимизатор более эффективно обрабатывает подзапросы в FROM пункт (то
есть, полученные таблицы):
Материализация подзапросов в FROM пункт откладывается,
пока их содержание не необходимо во время выполнения запроса, которое улучшает производительность:
Ранее, подзапросы в FROM пункт был
осуществлен для EXPLAIN
SELECT операторы. Это привело к частичному SELECT выполнение, даже при том, что цель EXPLAIN должен получить информацию о плане запроса, чтобы
не выполнить запрос. Эта материализация больше не происходит, таким образом, EXPLAIN быстрее для таких запросов.
Для не -EXPLAIN запросы, задержка материализации может привести к не
необходимости сделать это вообще. Рассмотрите запрос, который присоединяется к результату
подзапроса в FROM пункт к другой таблице: Если процессы
оптимизатора, что другая таблица сначала и находит, что не возвращает строк, соединение, не
должны быть выполнены далее, и оптимизатор может полностью пропустить осуществление
подзапроса.
Во время выполнения запроса оптимизатор может добавить индексирование к полученной таблице, чтобы ускорить извлечение строки от этого.
Рассмотрите следующий EXPLAIN оператор, для которого подзапрос появляется в FROM пункт a SELECT
запрос:
EXPLAIN SELECT * FROM (SELECT * FROM t1);
Оптимизатор избегает осуществлять подзапрос, задерживая это, пока результат не необходим во время SELECT
выполнение. В этом случае запрос не выполняется, таким образом, результат никогда не необходим.
Даже для запросов, которые выполняются, задержка материализации подзапроса может разрешить оптимизатору избегать
материализации полностью. Рассмотрите следующий запрос, который присоединяется к результату подзапроса в FROM пункт к другой таблице:
SELECT * FROM t1 JOIN (SELECT t2.f1 FROM t2) AS derived_t2 ON t1.f2=derived_t2.f1 WHERE t1.f1 > 0;
Если оптимизация обрабатывает t1 сначала и WHERE пункт
приводит к пустому результату, соединение должно обязательно быть пустым, и подзапрос не должен быть
осуществлен.
В худшем случае (полученные таблицы осуществляются), запросите выполнение, займет то же самое время в качестве перед MySQL 5.6.3, потому что никакая дополнительная работа не делается. В лучшем случае (полученные таблицы не осуществляются), запросите выполнение, будет более быстрым к тому времени, когда необходимый выполнить материализацию.
Для случаев, когда материализация требуется для подзапроса в FROM пункт,
оптимизатор может ускорить доступ к результату, добавляя индексирование к осуществленной таблице. Если такой
индексировать разрешил бы ref
доступ к таблице, это может значительно уменьшить объем данных, который должен быть считан во время выполнения
запроса. Рассмотрите следующий запрос:
SELECT * FROM t1 JOIN (SELECT * FROM t2) AS derived_t2 ON t1.f1=derived_t2.f1;
Оптимизатор создает индексирование по столбцу f1 от derived_t2
если выполнение так разрешило бы использование ref доступ для самого низкого плана выполнения стоимости. После добавления
индексирования оптимизатор может обработать осуществленную полученную таблицу то же самое как обычная таблица с
индексированием, и это извлекает выгоду так же из сгенерированного, индексируют. Издержки создания индекса
незначительны по сравнению со стоимостью выполнения запроса без индексирования. Если ref доступ привел бы к более высокой стоимости чем некоторый другой метод
доступа, нет индексировал бы, создается, и оптимизатор ничего не теряет.