войти зарегистрироваться

MySQL whois

индекс
202,61

EXPLAIN — Самая мощная команда MySQL

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

Как использовать команду EXPLAIN


Вот очень простой пример использования этой команды:

Схема базы данных:

(таблица с пользователями users)


(таблица с адресами address)


В этом примере производится выборка данных пользователя на основе его идентификатора (userid).
Вот то, что мы имеем в результате выполнения запроса EXPLAIN:

Переменная   Значение
  Идентификатор (ID) таблицы в запросе. EXPLAIN создает по одной записи для каждой таблицы в запросе.
  Возможные значения: SIMPLE, PRIMARY, UNION, DEPENDENT UNION, SUBSELECT, и DERIVED.
  Имя таблицы, из которой MySQL читает данные
  Тип объединения, которое использует MySQL. Возможные значения: eq_ref, ref, range, index, или all.
  Список индексов (или NULL, если индексов нет), которые MySQL может использовать для выборки рядов в таблице.
  Название индекса, который использует MySQL (после проверки всех возможных индексов).
  Размер ключа в байтах.
  Колонки или значения, которые используются для сравнения с ключем.
  Количество рядов, которые MySQL необходимо проверить, для обработки запроса.
  Дополнительная информация о запросе.

Этот пример достаточно прост. Мы производим поиск по первичному ключу (userid) и может быть только одна запись, которая подойдет нашим условиям (переменная rows равна 1).

Вот более расширенный пример:

Этот запрос более расширенный, чем первый. Он производит объединение таблиц users и address на основе userid. Поле userid – это первичный ключ таблицы users, но он не является индексом в таблице address. Результат выполнения команды EXPLAIN в этом случае будет следующий:
(таблица users)
Type: const
Possible_Keys: primary
Ref: const
(таблица address)
Type: all
Possible_Keys: (ничего)
Ref: (ничего)

Первая таблица является оптимизированной. Для выполнения запроса используется первичный ключ. Вторая таблица неоптимизирована. Значением параметра type является all, а Possible_keys пустой, что означает, что будет производиться полное сканирование таблицы. Добавление индекса к полю user второй таблицы сделает ее оптимизированной.
Результат вывода команды EXPLAIN после оптимизации второй таблицы будет следующим:
(таблица users)
Type: const
Possible_Keys: primary
Ref: const
(таблица address)
Type: const
Possible_Keys: primary
Ref: const

Дополнительную информацию о команде EXPLAIN вы можете найти в официальной документации MySQL: http://dev.mysql.com/doc/refman/5.0/en/e…

комментарии (31)

  • Сразу хочу уточнить: это перевод статьи. Я не знаю, почему автор выбрал именно такое название...
    • Ну вот! Не успел вчера половину перевести :(
  • Перевод хороший, статья не о чем. Про explain и так понятно, что средство мощное, вот если бы примеры позаковырестее, не такие явные, было бы и интересно и полезно.
    • Ну, для этого и есть на Хабре комментарии. WEB 2.0, никуда не денешься...
  • Примерно такое же описание можно найти в русской версии учебника.
    Статья не интересная, тема не раскрыта.
    • согласен.
      примеры: 2 посредственных,
      описание параметров: нет
  • Было бы интересно узнать, как определить в проекте узкие места при работе не с чистым SQL, а со всякими SQL toolkit-ами и Object Relational Mapper-ами
    • Например, включить журналирование долгих запросов. Или всех подряд.
  • Огромное спасибо! =)
  • Очень вовремя! Спасибо.
  • Не согласен с тем что с помощью EXPLAIN можно эфективно обнаруживать медленные запросы, потому что на детальный анализ большого числа различных возможных запросов (на CMS около 100) с помощью которых работает сложное веб-приложение будет потрачено слишком много времени.

    Для обнаружения медленных запросов можно использовать журнал медленных запросов, а после того как такие запросы будут выявлены провести их анализ с помощью EXPLAIN
    • Большинство запросов можно и на глаз анализировать, и увидеть есть в них проблемы или нет.
      И уже потом если что-то вызывает подозрение можно EXPLAIN-ить их.
      Также нужно учитывать какие запросы с какой переодичностью выполняются, если это например ежечасовый подсчет рейтинга по крону то 5-10 сек. можно ему и дать на обработку.
      Если же запрос выполняется очень часто, то и 1 (а то и меньше) сек. может стать раковой...

      Кстати в MySQL 5.1 есть возможность писать slow query log в таблицу, детальнее тут:
      http://www.mysqlperformanceblog.com/2007…
      Анализ запросов становиться еще более удобным, и можно даже автоматизировать процесс.
    • НЛО прилетело и опубликовало эту надпись здесь.
      • дайте пример, пожалуйста
        • Например запросы "SELECT field FROM table WHERE id=21", вызывающиеся 100 раз с разными id, вместо того чтобы выбрать их все одним запросом.
          • желательно при этом еще соединение с базой каждый раз устанавливать. для полного счастья т.с. ;)
          • совершенно некорректный пример
            читай внимательнее: "Вы можете написать запрос который будет выполнятся быстро, но сильно нагружать сревер, при частом выполнении будет жрать стлько ресурсов, сколько все "медленные" вместе взятые, которые выполняются изредко."
            перевожу: _1_ _быстрый_ _запрос_ который будет выполняться долго
            1 запрос с WHERE `id` = 666, с выставленным индексом по `id` будет выполняться быстрее любого запроса по неиндексированной таблице
            • Ага, видимо я понял про другую неоптимизированность (которую как раз ловят журналированием запросов). Тогда с тебя пример "быстрого запроса, выполняющегося долго".
              • ты высказал эту чудную идею - что "быстрый запрос" может выполняться медленно
                почему это я тогда должен приводить пример для твоего же утверждения? ;)
                • Ты потерял ключевой фрагмент - "при частом выполнении". То есть когда прсотенький с виду запрос выполняется так часто, что забивает сервер.
                  • ты можешь представить цифры, когда такой простой запрос будет выполняться медленнее?
                    ну и желательно - описать примерную ситуацию, когда на N лёгких запросов будет выполняться 1 тяжёлый
                    при этом N лёгких будут перевешивать сложный
                    • Представить цифры - вряд ли, да и неохота. Могу описать иногда возникающую ситуацию: инициализируется одновременно много объектов через ORM, для получения нескольких полей этих объектов. Выполнение одного сложного, но специально заточенного запроса - быстрее.
                      • "Выполнение одного сложного, но специально заточенного запроса - быстрее."
                        с этого места поподробнее
                        очень хотелось бы узнать критерии оценки "сложный" / "простой" запрос...
                      • собственно - грош цена тому ОРМ, который не умеет толком подтягивать зависимости в одном запросе
              • упс, вернее не совсем ты - DEL
                собственно у него и интересуйся....
                я придумать такого не могу
  • Жалкое подобие execution plan в mssql. Долго я мучался с mysql, пока не перешел на mssql express, и стал счастливым человеком :)
    • oracle execution plan тоже кладёт на обе лопатки мусикул
      • Согласен :)
    • Любой каприз за ваши деньги :)
      • mssql express совершенно бесплатен
  • А есть ли вообще планировщик и оптимизатор запросов в mysql?
Только авторизованные пользователи могут оставлять комментарии. Авторизуйтесь, пожалуйста.