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 text)

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

const row not found (JSON property: const_row_not_found)

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

Deleting all rows (JSON property: message)

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

Distinct (JSON property: distinct)

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

FirstMatch(tbl_name) (JSON property: first_match)

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

Full scan on NULL key (JSON property: message)

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

Impossible HAVING (JSON property: message)

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

Impossible WHERE (JSON property: message)

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

Impossible WHERE noticed after reading const tables (JSON property: message)

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

LooseScan(m..n) (JSON property: message)

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

No matching min/max row (JSON property: message)

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

no matching row in const table (JSON property: message)

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

No matching rows after partition pruning (JSON property: message)

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

No tables used (JSON property: 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 property: 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 is not ready yet (JSON property: none)

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

Range checked for each record (index map: N) (JSON property: 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 property: recursive)

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

Rematerialize (JSON property: rematerialize)

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

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

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

Scanned N databases (JSON property: message)

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

Select tables optimized away (JSON property: message)

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

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

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)

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

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.

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 использует оптимизацию сдвига вниз условия для повышения эффективности прямого сравнения неиндексированного столбца и константы. В таких случаях условие «сдвигается вниз» на узлы данных кластера и оценивается на всех узлах данных одновременно. Это исключает необходимость отправлять несоответствующие строки по сети и может ускорить такие запросы в 5–10 раз по сравнению с случаями, когда оптимизация сдвига вниз условия могла быть, но не использовалась. Дополнительную информацию см. в Разделе 10.2.1.5, «Оптимизация сдвига вниз условия движка».

Zero limit (JSON property: message)

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