Самая мощная команда в 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)
Статья не интересная, тема не раскрыта.
примеры: 2 посредственных,
описание параметров: нет
Для обнаружения медленных запросов можно использовать журнал медленных запросов, а после того как такие запросы будут выявлены провести их анализ с помощью EXPLAIN
И уже потом если что-то вызывает подозрение можно EXPLAIN-ить их.
Также нужно учитывать какие запросы с какой переодичностью выполняются, если это например ежечасовый подсчет рейтинга по крону то 5-10 сек. можно ему и дать на обработку.
Если же запрос выполняется очень часто, то и 1 (а то и меньше) сек. может стать раковой...
Кстати в MySQL 5.1 есть возможность писать slow query log в таблицу, детальнее тут:
http://www.mysqlperformanceblog.com/2007…
Анализ запросов становиться еще более удобным, и можно даже автоматизировать процесс.
читай внимательнее: "Вы можете написать запрос который будет выполнятся быстро, но сильно нагружать сревер, при частом выполнении будет жрать стлько ресурсов, сколько все "медленные" вместе взятые, которые выполняются изредко."
перевожу: _1_ _быстрый_ _запрос_ который будет выполняться долго
1 запрос с WHERE `id` = 666, с выставленным индексом по `id` будет выполняться быстрее любого запроса по неиндексированной таблице
почему это я тогда должен приводить пример для твоего же утверждения? ;)
ну и желательно - описать примерную ситуацию, когда на N лёгких запросов будет выполняться 1 тяжёлый
при этом N лёгких будут перевешивать сложный
с этого места поподробнее
очень хотелось бы узнать критерии оценки "сложный" / "простой" запрос...
собственно у него и интересуйся....
я придумать такого не могу