id (JSON name: select_id)

Идентификатор SELECT. Это последовательный номер SELECT в запросе. Значение может быть NULL, если строка относится к результату объединения других строк. В этом случае столбец table показывает значение, например, <unionM,N>, чтобы указать, что строка относится к объединению строк со значениями id в M и N.

select_type (JSON name: none)

Тип SELECT, который может быть любым из показанных в следующей таблице. JSON-форматированный EXPLAIN раскрывает тип SELECT как свойство query_block, если он не SIMPLE или PRIMARY. В таблице также показаны имена в формате JSON (применимо).

DEPENDENT обычно указывает на использование коррелированного подзапроса. См. Раздел 15.2.15.7, «Коррелированные подзапросы».

Вычисление DEPENDENT SUBQUERY отличается от вычисления UNCACHEABLE SUBQUERY. Для DEPENDENT SUBQUERY подзапрос пересчитывается только один раз для каждого набора различных значений переменных из его внешнего контекста. Для UNCACHEABLE SUBQUERY подзапрос пересчитывается для каждой строки внешнего контекста.

При указании FORMAT=JSON с EXPLAIN вывод не имеет единственного свойства, напрямую эквивалентного select_type; свойство query_block соответствует заданному SELECT. Доступны эквивалентные свойства большинства типов подзапросов SELECT (например, materialized_from_subquery для MATERIALIZED), и они отображаются при необходимости. Для SIMPLE и PRIMARY нет эквивалентов JSON.

Значение select_type для операторов, отличных от SELECT, отображает тип оператора для затронутых таблиц. Например, select_type равно DELETE для операторов DELETE.

table (JSON name: table_name)

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

partitions (JSON name: partitions)

Разделы, из которых записи будут сопоставляться запросом. Значение равно NULL для неразделенных таблиц. См. Раздел 26.3.5, «Получение информации о разделах».

type (JSON name: access_type)

Тип объединения. Описания разных типов см. в EXPLAIN Типы объединений.

possible_keys (JSON name: possible_keys)

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

Если этот столбец NULL (или не определен в JSON-выводе), соответствующих индексов нет. В этом случае вы можете улучшить производительность запроса, проверив пункт WHERE, чтобы узнать, относится ли он к какому-либо столбцу или столбцам, подходящим для индексирования. Если да, создайте соответствующий индекс и проверьте запрос с помощью EXPLAIN еще раз. См. Раздел 15.1.9, «Оператор ALTER TABLE».

Чтобы увидеть имеющиеся в таблице индексы, используйте SHOW INDEX FROM tbl_name.

key (JSON name: key)

Столбец key указывает ключ (индекс), который MySQL фактически решил использовать. Если MySQL принимает решение использовать один из possible_keys индексов для поиска строк, этот индекс перечислен как значение ключа.

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

Для InnoDB вторичный индекс может охватывать выбранные столбцы, даже если запрос также выбирает первичный ключ, потому что InnoDB хранит значение первичного ключа с каждым вторичным индексом. Если key равно NULL, MySQL не нашел индекс, который можно было бы использовать для более эффективного выполнения запроса.

Чтобы принудительно заставить MySQL использовать или игнорировать индекс, указанный в столбце possible_keys, используйте FORCE INDEX, USE INDEX или IGNORE INDEX в вашем запросе. См. Раздел 10.9.4, «Подсказки индексов».

Для MyISAM таблиц запуск ANALYZE TABLE помогает оптимизатору выбирать лучшие индексы. Для MyISAM таблиц myisamchk --analyze делает то же самое. См. Раздел 15.7.3.1, «Оператор ANALYZE TABLE» и Раздел 9.6, «Техническое обслуживание и восстановление после сбоев таблиц MyISAM».

key_len (JSON name: key_length)

Столбец key_len указывает длину ключа, которую MySQL решил использовать. Значение key_len позволяет определить, сколько частей составного ключа MySQL фактически использует. Если в столбце key указано NULL, то в столбце key_len также указано NULL.

Из-за формата хранения ключа длина ключа на один больше для столбца, который может быть NULL, чем для столбца NOT NULL.

ref (JSON name: ref)

Столбец ref показывает, какие столбцы или константы сравниваются с индексом, указанным в столбце key, для выбора строк из таблицы.

Если значение равно func, то используемое значение является результатом некоторой функции. Чтобы увидеть, какая функция, используйте SHOW WARNINGS после EXPLAIN, чтобы увидеть расширенный EXPLAIN вывод. Функция может быть фактически оператором, таким как арифметический оператор.

rows (JSON name: rows)

Столбец rows указывает количество строк, которое, по мнению MySQL, необходимо просмотреть для выполнения запроса.

Для таблиц InnoDB это число является оценкой и может не всегда быть точным.

filtered (JSON name: filtered)

Столбец filtered указывает приблизительный процент строк таблицы, отфильтрованных условием таблицы. Максимальное значение равно 100, что означает, что не произошло фильтрации строк. Уменьшение значений от 100 указывает на увеличение объёма фильтрации. rows показывает количество оценённых просмотренных строк, а rows × filtered показывает количество строк, которые объединяются со следующей таблицей. Например, если rows равен 1000, а filtered равен 50,00 (50%), то количество строк для объединения со следующей таблицей составляет 1000 × 50% = 500.

Extra (JSON name: none)

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

Нет единственного JSON свойства, соответствующего столбцу Extra; однако значения, которые могут встречаться в этом столбце, представлены как JSON свойства или как текст свойства message.

Backward index scan (JSON: backward_index_scan)

Оптимизатор может использовать обратный индекс в таблице InnoDB. Отображается вместе с Using index. Дополнительная информация в разделе Раздел 10.3.13, «Обратные индексы».

Child of 'table' pushed join@1 (JSON: message текст)

Эта таблица указана как дочерняя для table в объединении, которое может быть перенесено в ядро NDB. Применяется только в кластере NDB, если включены переносимые объединения. Смотрите описание системной переменной сервера ndb_join_pushdown для получения дополнительной информации и примеров.

const row not found (JSON свойство: const_row_not_found)

Для запроса, такого как SELECT ... FROM tbl_name, таблица была пустой.

Deleting all rows (JSON свойство: message)

Для DELETE, некоторые типы хранилищ (такие как MyISAM) поддерживают метод обработчика, который удаляет все строки таблицы простым и быстрым способом. Это значение Extra отображается, если движок использует эту оптимизацию.

Distinct (JSON свойство: distinct)

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

FirstMatch(tbl_name) (JSON свойство: first_match)

Для tbl_name используется стратегия сокращения объединения FirstMatch.

Full scan on NULL key (JSON свойство: message)

Это происходит при оптимизации подзапросов в качестве стратегии по умолчанию, когда оптимизатор не может использовать метод доступа с помощью индекса.

Impossible HAVING (JSON свойство: message)

Оператор HAVING всегда ложный и не может выбрать ни одной строки.

Impossible WHERE (JSON свойство: message)

Оператор WHERE всегда ложный и не может выбрать ни одной строки.

Impossible WHERE noticed after reading const tables (JSON свойство: message)

MySQL прочитал все таблицы const (и system) и заметил, что оператор WHERE всегда ложный.

LooseScan(m..n) (JSON свойство: message)

Используется стратегия LooseScan для полуобъединения. m и n — ключевые номера деталей.

No matching min/max row (JSON свойство: message)

Ни одна строка не удовлетворяет условию для запроса, такого как SELECT MIN(...) FROM ... WHERE condition.

no matching row in const table (JSON свойство: message)

Для запроса с объединением была пустая таблица или таблица без строк, удовлетворяющих условию уникального индекса.

No matching rows after partition pruning (JSON свойство: message)

Для DELETE или UPDATE оптимизатор не обнаружил ничего для удаления или обновления после обрезки раздела. Это аналогично значению Impossible WHERE для операторов SELECT.

No tables used (JSON свойство: message)

Запрос не содержит оператор FROM или содержит оператор FROM DUAL.

Для операторов INSERT или REPLACE EXPLAIN отображает это значение, когда нет части SELECT. Например, это появляется для EXPLAIN INSERT INTO t VALUES(10), так как это эквивалентно EXPLAIN INSERT INTO t SELECT 10 FROM DUAL.

Not exists (JSON свойство: message)

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

SELECT * FROM t1 LEFT JOIN t2 ON t1.id=t2.id
  WHERE t2.id IS NULL;

Предположим, что t2.id определено как NOT NULL. В этом случае MySQL сканирует t1 и ищет строки в t2 с использованием значений t1.id. Если MySQL находит соответствующую строку в t2, он понимает, что t2.id никогда не может быть NULL, и не сканирует остальные строки в t2, имеющие то же значение id. Другими словами, для каждой строки в t1 MySQL должен выполнить только один поиск в t2, независимо от того, сколько строк фактически соответствует в t2.

Это также может указывать на то, что условие WHERE формы NOT IN (subquery) или NOT EXISTS (subquery) было преобразовано во внутреннее антиобъединение. Это удаляет подзапрос и вносит его таблицы в план для самого верхнего запроса, обеспечивая улучшенное планирование стоимости. Объединяя полуобъединения и антиобъединения, оптимизатор может более свободно переупорядочивать таблицы в плане выполнения, в некоторых случаях создавая более быстрый план.

Вы можете увидеть, когда выполняется преобразование антиобъединения для данного запроса, проверив столбец Message из SHOW WARNINGS после выполнения EXPLAIN или в выводе EXPLAIN FORMAT=TREE.

Plan isn't ready yet (JSON свойство: none)

Это значение появляется с EXPLAIN FOR CONNECTION, когда оптимизатор не завершил создание плана выполнения для оператора, выполняющегося в указанном подключении. Если вывод плана выполнения содержит несколько строк, любая или все из них могут иметь это значение Extra, в зависимости от прогресса оптимизатора при определении полного плана выполнения.

Range checked for each record (index map: N) (JSON свойство: message)

MySQL не нашел подходящего индекса, но обнаружил, что некоторые индексы могут быть использованы после того, как станут известны значения столбцов из предыдущих таблиц. Для каждой комбинации строк в предыдущих таблицах MySQL проверяет, можно ли использовать метод доступа range или index_merge для извлечения строк. Это не очень быстро, но быстрее, чем выполнение объединения без индекса вообще. Критерии применимости описаны в Разделе 10.2.1.2, «Оптимизация диапазонов» и Разделе 10.2.1.3, «Оптимизация слияния индексов», за исключением того, что все значения столбцов для предыдущей таблицы известны и считаются константами.

Индексы пронумерованы, начиная с 1, в том же порядке, что и в SHOW INDEX для таблицы. Значение карты индексов N — значение маски бита, указывающее, какие индексы являются кандидатами. Например, значение 0x19 (двоичное 11001) означает, что индексы 1, 4 и 5 рассматриваются.

Recursive (JSON свойство: recursive)

Это указывает, что строка относится к рекурсивной части оператора SELECT в рекурсивном общем табличном выражении. См. Раздел 15.2.20, «WITH (Общие табличные выражения)».

Rematerialize (JSON свойство: rematerialize)

Rematerialize (X,...) отображается в строке EXPLAIN для таблицы T, где X — любая латеральная производная таблица, рематериалзация которой запускается при чтении новой строки T. Например:

SELECT
  ...
FROM
  t,
  LATERAL (derived table that refers to t) AS dt
...

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

Scanned N databases (JSON свойство: message)

Это показывает, сколько сканирований каталога выполняет сервер при обработке запроса для таблиц INFORMATION_SCHEMA, как описано в Разделе 10.2.3, «Оптимизация запросов INFORMATION_SCHEMA». Значение N может быть 0, 1 или all.

Select tables optimized away (JSON property: message)

Оптимизатор определил, что 1) должно быть возвращено не более одной строки и 2) для создания этой строки необходимо прочитать детерминированный набор строк. Когда строки, которые нужно прочитать, можно прочитать на стадии оптимизации (например, считывая строки индекса), нет необходимости читать какие-либо таблицы во время выполнения запроса.

Первое условие выполняется, когда запрос неявно сгруппирован (содержит агрегатную функцию, но не содержит клаузу GROUP BY). Второе условие выполняется, когда по каждому используемому индексу выполняется поиск одной строки. Количество прочитанных индексов определяет количество строк для чтения.

Рассмотрим следующий неявно сгруппированный запрос:

SELECT MIN(c1), MIN(c2) FROM t1;

Предположим, что MIN(c1) можно получить, прочитав одну строку индекса, а MIN(c2) можно получить, прочитав одну строку из другого индекса. То есть для каждого столбца c1 и c2 существует индекс, где столбец является первым столбцом индекса. В этом случае возвращается одна строка, созданная путём чтения двух детерминированных строк.

Это значение Extra не возникает, если строки для чтения не детерминированы. Рассмотрим этот запрос:

SELECT MIN(c2) FROM t1 WHERE c1 <= 10;

Предположим, что (c1, c2) является покрывающим индексом. Используя этот индекс, для поиска минимального значения c2 необходимо просканировать все строки с c1 <= 10. В отличие от этого, рассмотрим этот запрос:

SELECT MIN(c2) FROM t1 WHERE c1 = 10;

В этом случае первая строка индекса с c1 = 10 содержит минимальное значение c2. Для получения возвращаемой строки необходимо прочитать только одну строку.

Для систем хранения, которые поддерживают точное количество строк на таблицу (например, MyISAM, но не InnoDB), это значение Extra может возникнуть для запросов COUNT(*), для которых клаузы WHERE отсутствуют или всегда истинны, и нет клаузы GROUP BY. (Это пример неявно сгруппированного запроса, где система хранения влияет на то, можно ли прочитать детерминированное количество строк.)

Skip_open_table, Open_frm_only, Open_full_table (JSON property: message)

Эти значения указывают на оптимизации открытия файлов, которые применяются к запросам для таблиц INFORMATION_SCHEMA.

Start temporary, End temporary (JSON property: message)

Это указывает на использование временных таблиц для стратегии semijoin Duplicate Weedout.

unique row not found (JSON property: message)

Для запроса, такого как SELECT ... FROM tbl_name, ни одна строка не удовлетворяет условию для индекса UNIQUE или PRIMARY KEY в таблице.

Using filesort (JSON property: using_filesort)

MySQL должен выполнить дополнительный проход, чтобы выяснить, как получить строки в отсортированном порядке. Сортировка выполняется путём просмотра всех строк в соответствии с типом соединения и хранения ключа сортировки и указателя на строку для всех строк, которые соответствуют клаузе WHERE. Затем ключи сортируются, и строки извлекаются в отсортированном порядке. См. Раздел 10.2.1.16, «Оптимизация ORDER BY».

Using index (JSON property: using_index)

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

Для таблиц InnoDB с пользовательским кластеризованным индексом, этот индекс может использоваться даже в случае отсутствия Using index в столбце Extra. Это так, если type является index и key является PRIMARY.

Информация обо всех используемых покрывающих индексах отображается для EXPLAIN FORMAT=TRADITIONAL и EXPLAIN FORMAT=JSON. Она также отображается для EXPLAIN FORMAT=TREE.

Using index condition (JSON property: using_index_condition)

Таблицы считываются путём доступа к кортежам индексов и их проверки для определения необходимости чтения полных строк таблицы. Таким образом, информация индекса используется для отсрочки (“сдвиг вниз”) чтения полных строк таблицы, если это не требуется. См. Раздел 10.2.1.6, «Оптимизация сдвигом вниз условий индекса».

Using index for group-by (JSON property: using_index_for_group_by)

Подобно методу доступа к таблицам Using index, Using index for group-by указывает, что MySQL нашёл индекс, который может использоваться для извлечения всех столбцов запроса GROUP BY или DISTINCT без дополнительных обращений к диску к фактической таблице. Кроме того, индекс используется наиболее эффективным образом, так что для каждой группы считывается только несколько записей индекса. Для подробностей см. Раздел 10.2.1.17, «Оптимизация GROUP BY».

Using index for skip scan (JSON property: using_index_for_skip_scan)

Указывает, что используется метод доступа Skip Scan. См. Skip Scan Range Access Method.

Using join buffer (Block Nested Loop), Using join buffer (Batched Key Access), Using join buffer (hash join) (JSON property: using_join_buffer)

Таблицы из предыдущих соединений считываются частями в буфер соединения, а затем их строки используются из буфера для выполнения соединения с текущей таблицей. (Block Nested Loop) указывает использование алгоритма Block Nested-Loop, (Batched Key Access) указывает использование алгоритма Batched Key Access, а (hash join) указывает использование соединения с хешем. То есть ключи из таблицы на строке перед строкой EXPLAIN вывода буферизуются, а соответствующие строки извлекаются порциями из таблицы, представленной строкой, в которой появляется Using join buffer.

В JSON-форматированном выводе значение using_join_buffer всегда является одним из Block Nested Loop, Batched Key Access или hash join.

Для получения дополнительной информации о соединениях с хешем см. Раздел 10.2.1.4, «Оптимизация соединения с хешем».

См. Соединения с использованием алгоритма Batched Key Access для получения информации об алгоритме Batched Key Access.

Using MRR (JSON property: message)

Таблицы считываются с помощью стратегии оптимизации Multi-Range Read. См. Раздел 10.2.1.11, «Оптимизация Multi-Range Read».

Using sort_union(...), Using union(...), Using intersect(...) (JSON property: message)

Эти значения указывают на конкретный алгоритм, демонстрирующий, как объединяются сканирования индексов для типа соединения index_merge. См. Раздел 10.2.1.3, «Оптимизация слияния индексов».

Using temporary (JSON property: using_temporary_table)

Для решения запроса MySQL необходимо создать временную таблицу для хранения результата. Это обычно происходит, если запрос содержит клаузы GROUP BY и ORDER BY, которые перечисляют столбцы по-разному.

Using where (JSON property: attached_condition)

Клауза WHERE используется для ограничения строк, которые будут сопоставлены с следующей таблицей или отправлены клиенту. Если вы не намерены извлекать или проверять все строки из таблицы, возможно, есть ошибка в вашем запросе, если значение Extra не равно Using where, а тип соединения таблиц равен ALL или index.

Using where не имеет прямого аналога в JSON-выводе; свойство attached_condition содержит любое условие WHERE.

Using where with pushed condition (JSON property: message)

Этот пункт относится NDB таблицам только. Это означает, что NDB Cluster использует оптимизацию Condition Pushdown для повышения эффективности прямого сравнения неиндексированного столбца и константы. В таких случаях условие “сдвигается вниз” до узлов данных кластера и оценивается на всех узлах данных одновременно. Это исключает необходимость отправки несоответствующих строк по сети и может ускорить такие запросы в 5-10 раз по сравнению со случаями, когда оптимизация Condition Pushdown могла бы быть, но не используется. Для получения дополнительной информации см. Раздел 10.2.1.5, «Оптимизация сдвигом вниз условия движка».

Zero limit (JSON property: message)

В запросе была клауза LIMIT 0 и он не может выбрать ни одной строки.