blockdog Jun 22 2007 at 17:28

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

2 min

160K

MySQL*

Translation

+18

Comments 33

blockdog Jun 22 2007 at 18:07

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

korchasa Jun 22 2007 at 18:43

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

nonSmoker Jun 22 2007 at 19:42

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

blockdog Jun 22 2007 at 20:55

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

jiexaspb Jun 22 2007 at 21:26

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

z1nkum Jun 24 2007 at 00:19

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

Goodrone Jun 22 2007 at 21:29

Было бы интересно узнать, как определить в проекте узкие места при работе не с чистым SQL, а со всякими SQL toolkit-ами и Object Relational Mapper-ами

glader Jun 22 2007 at 22:31

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

umnik Jun 22 2007 at 21:48

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

dir01 Jun 23 2007 at 00:32

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

xOr Jun 23 2007 at 00:33

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

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

aver Jun 23 2007 at 12:59

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

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

DEL Jun 23 2007 at 13:03

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

sattu Jun 23 2007 at 14:32

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

glader Jun 23 2007 at 22:15

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

pietrovich Jun 23 2007 at 22:20

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

zerkms Jun 24 2007 at 14:37

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

glader Jun 24 2007 at 15:00

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

zerkms Jun 24 2007 at 15:24

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

glader Jun 24 2007 at 15:35

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

zerkms Jun 24 2007 at 16:24

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

glader Jun 24 2007 at 16:31

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

zerkms Jun 24 2007 at 16:41

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

zerkms Jun 24 2007 at 16:43

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

zerkms Jun 24 2007 at 15:27

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

postgree Nov 16 2013 at 11:41

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