@blockdog22 июн 2007 в 13:28

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

2 мин

163K

MySQL *

Перевод

+18

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

@blockdog 22 июн 2007 в 14:07

Сразу хочу уточнить: это перевод статьи. Я не знаю, почему автор выбрал именно такое название...

@korchasa 22 июн 2007 в 14:43

Ну вот! Не успел вчера половину перевести :(

@nonSmoker 22 июн 2007 в 15:42

Перевод хороший, статья не о чем. Про explain и так понятно, что средство мощное, вот если бы примеры позаковырестее, не такие явные, было бы и интересно и полезно.

@blockdog 22 июн 2007 в 16:55

Ну, для этого и есть на Хабре комментарии. WEB 2.0, никуда не денешься...

@jiexaspb 22 июн 2007 в 17:26

Примерно такое же описание можно найти в русской версии учебника.
Статья не интересная, тема не раскрыта.

@z1nkum 23 июн 2007 в 20:19

согласен.
примеры: 2 посредственных,
описание параметров: нет

НЛО прилетело и опубликовало эту надпись здесь

@glader 22 июн 2007 в 18:31

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

@umnik 22 июн 2007 в 17:48

Огромное спасибо! =)

@dir01 22 июн 2007 в 20:32

Очень вовремя! Спасибо.

@xOr 22 июн 2007 в 20:33

Не согласен с тем что с помощью EXPLAIN можно эфективно обнаруживать медленные запросы, потому что на детальный анализ большого числа различных возможных запросов (на CMS около 100) с помощью которых работает сложное веб-приложение будет потрачено слишком много времени.

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

@aver 23 июн 2007 в 08:59

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

Кстати в MySQL 5.1 есть возможность писать slow query log в таблицу, детальнее тут:
http://www.mysqlperformanceblog.com/2007…
Анализ запросов становиться еще более удобным, и можно даже автоматизировать процесс.

@DEL 23 июн 2007 в 09:03

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

@sattu 23 июн 2007 в 10:32

дайте пример, пожалуйста

@glader 23 июн 2007 в 18:15

Например запросы "SELECT field FROM table WHERE id=21", вызывающиеся 100 раз с разными id, вместо того чтобы выбрать их все одним запросом.

@pietrovich 23 июн 2007 в 18:20

желательно при этом еще соединение с базой каждый раз устанавливать. для полного счастья т.с. ;)

@zerkms 24 июн 2007 в 10:37

совершенно некорректный пример
читай внимательнее: "Вы можете написать запрос который будет выполнятся быстро, но сильно нагружать сревер, при частом выполнении будет жрать стлько ресурсов, сколько все "медленные" вместе взятые, которые выполняются изредко."
перевожу: _1_ _быстрый_ _запрос_ который будет выполняться долго
1 запрос с WHERE `id` = 666, с выставленным индексом по `id` будет выполняться быстрее любого запроса по неиндексированной таблице

@glader 24 июн 2007 в 11:00

Ага, видимо я понял про другую неоптимизированность (которую как раз ловят журналированием запросов). Тогда с тебя пример "быстрого запроса, выполняющегося долго".

@zerkms 24 июн 2007 в 11:24

ты высказал эту чудную идею - что "быстрый запрос" может выполняться медленно
почему это я тогда должен приводить пример для твоего же утверждения? ;)

@glader 24 июн 2007 в 11:35

Ты потерял ключевой фрагмент - "при частом выполнении". То есть когда прсотенький с виду запрос выполняется так часто, что забивает сервер.

@zerkms 24 июн 2007 в 12:24

ты можешь представить цифры, когда такой простой запрос будет выполняться медленнее?
ну и желательно - описать примерную ситуацию, когда на N лёгких запросов будет выполняться 1 тяжёлый
при этом N лёгких будут перевешивать сложный

@glader 24 июн 2007 в 12:31

Представить цифры - вряд ли, да и неохота. Могу описать иногда возникающую ситуацию: инициализируется одновременно много объектов через ORM, для получения нескольких полей этих объектов. Выполнение одного сложного, но специально заточенного запроса - быстрее.

@zerkms 24 июн 2007 в 12:41

"Выполнение одного сложного, но специально заточенного запроса - быстрее."
с этого места поподробнее
очень хотелось бы узнать критерии оценки "сложный" / "простой" запрос...

@zerkms 24 июн 2007 в 12:43

собственно - грош цена тому ОРМ, который не умеет толком подтягивать зависимости в одном запросе

@zerkms 24 июн 2007 в 11:27

упс, вернее не совсем ты - DEL
собственно у него и интересуйся....
я придумать такого не могу

@postgree 16 ноя 2013 в 07:41

«Быстрые запросы», которые жрут много ресурсов xD
Я представляю такое только с фулсканом индексов (не таблиц). Проблемы с этим возникают только в HA на OLTP в многопроцессорных системах (из опыта). Синхронизация кешей процессоров. Но в этот момент запросы перестанут быть быстрыми.