И швец, и жнец, и на дуде игрец
0,0
рейтинг
22 июня 2007 в 17:28

Разработка → 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: dev.mysql.com/doc/refman/5.0/en/explain.html
Перевод: Justin Silverton
[BlockDog] @blockdog
карма
22,6
рейтинг 0,0
И швец, и жнец, и на дуде игрец
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Разработка

Комментарии (33)

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

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

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

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.