Spec-Zone .ru
спецификации, руководства, описания, API

8.8.2. EXPLAIN Выходной Формат

EXPLAIN оператор предоставляет информацию о плане выполнения относительно a SELECT оператор.

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

Когда EXTENDED ключевое слово используется, EXPLAIN производит дополнительную информацию, которая может быть просмотрена, выходя a SHOW WARNINGS оператор после EXPLAIN оператор. EXPLAIN EXTENDED также дисплеи filtered столбец. См. Раздел 8.8.3,"EXPLAIN EXTENDED Выходной Формат".

Отметить

Невозможно использовать EXTENDED и PARTITIONS ключевые слова вместе в том же самом EXPLAIN оператор.

EXPLAIN Выходные Столбцы

Этот раздел описывает выходные столбцы, произведенные EXPLAIN. Более поздние разделы обеспечивают дополнительную информацию о type и Extra столбцы.

Каждая выходная строка от EXPLAIN предоставляет информацию об одной таблице. Каждая строка содержит значения, полученные в итоге в Таблице 8.1,"EXPLAIN Выходные Столбцы", и описали более подробно после таблицы.

Таблица 8.1. EXPLAIN Выходные Столбцы

Столбец Значение
id SELECT идентификатор
select_type SELECT ввести
table Таблица для выходной строки
partitions Соответствующие разделы
type Тип соединения
possible_keys Возможное индексирует, чтобы выбрать
key Индексирование фактически выбранный
key_len Длина выбранного ключа
ref Столбцы по сравнению с индексированием
rows Оценка строк, которые будут исследованы
filtered Процент строк фильтруется по табличному условию
Extra Дополнительная информация

EXPLAIN Типы соединения

type столбец EXPLAIN вывод описывает, как присоединяются к таблицам. Следующий список описывает типы соединения, упорядоченные от лучшего типа до худшего:

EXPLAIN Дополнительная информация

Extra столбец EXPLAIN вывод содержит дополнительную информацию о том, как MySQL разрешает запрос. Следующий список объясняет значения, которые могут появиться в этом столбце. Если Вы хотите сделать свои запросы с такой скоростью, как возможный, высматривать Extra значения Using filesort и Using temporary.

EXPLAIN Выходная Интерпретация

Можно получить хорошую индикацию относительно того, насколько хороший соединение, принимая продукт значений rows столбец EXPLAIN вывод. Это должно сказать Вам примерно, сколько MySQL строк должен исследовать, чтобы выполнить запрос. Если Вы ограничиваете запросы с max_join_size системная переменная, этот продукт строки также используется, чтобы определить который многократная таблица SELECT операторы, чтобы выполниться и чтобы прерваться. См. Раздел 8.11.2, "Настраивая Параметры Сервера".

Следующий пример показывает, как многократно-табличное соединение может быть оптимизировано прогрессивно основанное на информации, предоставленной EXPLAIN.

Предположите, что Вы имеете SELECT оператор, показанный здесь и что Вы планируете исследовать это использование EXPLAIN: 

EXPLAIN SELECT tt.TicketNumber, tt.TimeIn,               tt.ProjectReference, tt.EstimatedShipDate,               tt.ActualShipDate, tt.ClientID,               tt.ServiceCodes, tt.RepetitiveID,               tt.CurrentProcess, tt.CurrentDPPerson,               tt.RecordVolume, tt.DPPrinted, et.COUNTRY,               et_1.COUNTRY, do.CUSTNAME        FROM tt, et, et AS et_1, do        WHERE tt.SubmitTime IS NULL          AND tt.ActualPC = et.EMPLOYID          AND tt.AssignedPC = et_1.EMPLOYID          AND tt.ClientID = do.CUSTNMBR;

Для этого примера сделайте следующие предположения:

Первоначально, прежде, чем любая оптимизация была выполнена, EXPLAIN оператор производит следующую информацию: 

table type possible_keys key  key_len ref  rows  Extraet    ALL  PRIMARY       NULL NULL    NULL 74do    ALL  PRIMARY       NULL NULL    NULL 2135et_1  ALL  PRIMARY       NULL NULL    NULL 74tt    ALL  AssignedPC,   NULL NULL    NULL 3872           ClientID,           ActualPC      Range checked for each record (index map: 0x23)

Поскольку type ALL для каждой таблицы этот вывод указывает, что MySQL генерирует Декартово произведение всех таблиц; то есть, каждая комбинация строк. Это занимает вполне длительное время, потому что продукт числа строк в каждой таблице должен быть исследован. Для случая под рукой, этот продукт является 74 × 2135 × 74 × 3872 = 45,268,558,720 строк. Если бы таблицы были больше, можно только вообразить, сколько времени это взяло бы.

Одна проблема здесь состоит в том, что MySQL может использовать, индексирует на столбцах более эффективно, если они объявляются как тот же самый тип и размер. В этом контексте, VARCHAR и CHAR считаются тем же самым, если они объявляются как тот же самый размер. tt.ActualPC объявляется как CHAR(10) и et.EMPLOYID CHAR(15), таким образом, есть несоответствие длины.

Чтобы фиксировать эту несоизмеримость между длинами столбца, использовать ALTER TABLE удлинить ActualPC от 10 символов до 15 символов: 

mysql> ALTER TABLE tt MODIFY ActualPC
        VARCHAR(15);

Теперь tt.ActualPC и et.EMPLOYID оба VARCHAR(15). Выполнение EXPLAIN оператор снова приводит к этому результату: 

table type   possible_keys key     key_len ref         rows    Extratt    ALL    AssignedPC,   NULL    NULL    NULL        3872    Using             ClientID,                                         where             ActualPCdo    ALL    PRIMARY       NULL    NULL    NULL        2135      Range checked for each record (index map: 0x1)et_1  ALL    PRIMARY       NULL    NULL    NULL        74      Range checked for each record (index map: 0x1)et    eq_ref PRIMARY       PRIMARY 15      tt.ActualPC 1

Это не совершенно, но намного лучше: продукт rows значения меньше фактором 74. Через несколько секунд выполняется эта версия.

Второе изменение может быть сделано устранить несоответствия длины столбца для tt.AssignedPC = et_1.EMPLOYID и tt.ClientID = do.CUSTNMBR сравнения: 

mysql> ALTER TABLE tt MODIFY AssignedPC
        VARCHAR(15),    ->                MODIFY ClientID
        VARCHAR(15);

После той модификации, EXPLAIN производит вывод, показанный здесь: 

table type   possible_keys key      key_len ref           rows Extraet    ALL    PRIMARY       NULL     NULL    NULL          74tt    ref    AssignedPC,   ActualPC 15      et.EMPLOYID   52   Using             ClientID,                                         where             ActualPCet_1  eq_ref PRIMARY       PRIMARY  15      tt.AssignedPC 1do    eq_ref PRIMARY       PRIMARY  15      tt.ClientID   1

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

mysql> ANALYZE TABLE tt;

С дополнительным индексируют информацию, соединение совершенно и EXPLAIN приводит к этому результату: 

table type   possible_keys key     key_len ref           rows Extratt    ALL    AssignedPC    NULL    NULL    NULL          3872 Using             ClientID,                                        where             ActualPCet    eq_ref PRIMARY       PRIMARY 15      tt.ActualPC   1et_1  eq_ref PRIMARY       PRIMARY 15      tt.AssignedPC 1do    eq_ref PRIMARY       PRIMARY 15      tt.ClientID   1

Отметьте что rows столбец в выводе от EXPLAIN образованное предположение от оптимизатора соединения MySQL. Проверьте, являются ли числа даже близко к истине, сравниваясь rows продукт с фактическим числом строк, которые возвращает запрос. Если числа очень отличаются, Вы могли бы получить лучшую производительность при использовании STRAIGHT_JOIN в Вашем SELECT оператор и пытающийся перечислить таблицы в различном порядке в FROM пункт.

Возможно в некоторых случаях выполнить операторы, которые изменяют данные когда EXPLAIN SELECT используется с подзапросом; для получения дополнительной информации см. Раздел 13.2.10.8, "Подзапросы в FROM Пункт".

Авторское право © 1997, 2013, Oracle и/или его филиалы. Все права защищены. Официальные уведомления
Домой