Как выявить медленные SQL запросы?

[@blockdog]

Если вы нашли в тексте неточность, опечатку, или ошибку, пожалуйста, сообщите об этом в комментариях.

[@zerkms]

вот хорошая тема в продолжение http://www.mysqlperformanceblog.com/2007…

[@blockdog]

Спасибо, почитаю.

[@redhummer]

Не нужно бояться "долгих" запросов. Нужно дружиться с кешированием и InnoDB.

[@zerkms]

разве долгие запросы - не сигнал о том, что "что-то не в порядке с индесами и запросами"?
имхо цель кеширования - не залатать проблемы с неумением работать с индексами, а увеличить производительность и так уже оптимизированной бд

[@redhummer]

Не сигнал. А кто вообще кэшированием латает пробллемы с БД? Я говорю о тех случаях, когда медленных запросов не избежать, предполагая, что разработчик БД не ленив и потратил нужное время на её проектирование и осмысление.

[@pietrovich]

имхо, данные советы отночятся как раз к этапу "разработчик БД не ленив и потратил нужное время на её проектирование и осмысление". т.е. в процессе "осмысления" подобные рекомендации ему могут пригодиться :)

[@smart]

Согласен, если долгие запросы выполняются с Вашего ведома - ничего страшного в этом нет. Но все же - бояться не нужно, нужно знать ;)

[@WebByte]

Да что Вы говорите? А может приведёте пример тестов, где ИнноДБ на селектах явно превосходит МайИсам?

[@bendingunit22]

Иногда альтернативы InnoDB нет.

[@WebByte]

Ну альтернативы-то есть всегда. Только не в рамках MySQL. Но на БД в основном с селектами MyISAM — вполне себе альтернатива для InnoDB

[@Siddthartha]

причем тут селекты, разве преимущество иннодб в первую очередь не в поддержке транзакций?
иногда они необходимы и тогда майизам теряет смысл.

[@redhummer]

Я говорю о поддержке транзакций (к скорости это отношения не имеет) и каскадных операциях (вот тут уже стоит задуматься).
InnoDB проиграет в скорости на примитивном селекте MyISAM, но когда понимаешь, что удаляя, либо изменяя некую строку в одной таблице, можно каскадно удалить/изменить данные в сколь угодно многих свзянных таблицах всего лишь одним запросом с гарантированной надёжностью, то становятся очевидными приимущества InnoDB.
Потому я и говорил выше InnoDB + вменяемое кэширование == Крест на MyISAM.
P.S. Я долго сидел на MyISAM и в действительности убеждён, что это самый быстрый тип БД MySQL. Но времена и требования от проекта к проекту меняются. Изменились и мои предпочтения.

[@redhummer]

Просто, IMHO, если вы работаете в MyISAM и у вас долго выполняются запросы, значит:
а. Вы просто напортачили в планировании БД
б. Вы не напортачили с БД, но просто такой рисковый парень, что готовы потерять данные, используя тип БД без поддержки транзакций.

[@WebByte]

Я вообще Мускул не использую, больно убогая БД.
И подходы к медленности запросов у нас с Вами разные

[@WebByte]

В последнее время не использую

[@redhummer]

Буду рад, если вы в пм отпишите, с чем работать стоит. Без иронии и шуток.

[@crash]

А можно мне продублировать, тоже интересно? :)

[@WebByte]

Те же Постгресс и Оракл. Транзакции у них, ессесн, есть, а возможности в плане выполнения выборок все ж помощнее Мускуловых. Про другие промышленные СУБД ничего сказать не могу — не использовал. Сравнение с Мускулом в рамках треда не распишу, не та тематика, да и статей на эту тему полно.

[@redhummer]

Оракл... Оно платное. Я видел как оно работает. Страшно. Я трудностей не боюсь, но симбиоза живого организма и компьютерной программы (да, программы) — опасаюсь (:

[@WebByte]

MySQL тоже платная для коммерческого использования (сюрприз, да?).

Для изучения Оракл вполне бесплатен и скачивается непосредственно с их сайта. Другое дело, что всякие патчи и апдейты недоступны. Но поиграться даже в серьёзные вещи вполне можно. И не так страшен Оракл, как его малюют. Хотя после Мускула первое время будет непривычно, да.

[@pietrovich]

с каких это пор у мускула кроме платной поддержки появилась еще и платная эксплуатация !? всех хостеров арестовываем за контрафакт, ага?

[@WebByte]

Мне приводить здесь тексты лицензий или сами «асилите» в каких случаях используется GPL, а в каких коммерческая лицензия?

[@pietrovich]

перечитал FAQ по лицензированию MySQL, так и не понял, где именно "MySQL тоже платная для коммерческого использования (сюрприз, да?)."

вы ничего не путаете? а то словами типа GPL вы бросаться научились, а ссылками нет. жаль ...

[@thorn]

очень простой тест - 100 потоков делают SELECT, INSERT, UPDATE в одну таблицу.
в это случае MyISAM большинство времени будет простаивать на блокировке таблицы, а InnoDB в свою очередь будет простаивать только на блокировке строки или блокировки части индекса, в зависимости от того, какой уровень сериализации у вас.
Второй момент, чем плох MyISAM - часто бьются таблицы при большой нагрузке, что вообще неприемлемо для некоторых задач.

[@WebByte]

Я спрашивал про Селекты, а не еще и Инсерты / Апдейты.
Так то прекрасно знаю, что такое локи в MyISAM.

[@thorn]

проглядел :) в случае когда данных больше чем кеша и фиксированный размер строки в myisam это верно. я никогда не делал тестов когда индексы/данные полностью помещаются в кеш mysql. подозреваю, что тогда разница не очень большой будет.

[@glader]

Надеюсь в следующей серии прочитать подробное описание EXPLAIN

[@AirWorker]

При разработке ПО можно использовать встроенный в приложение профайлер БД. Например, в Zend Framework есть замечательный довольно гибкий профайлер.

[@redhummer]

Да вообще скорость выполнения любого запроса (пример PHP) можно замерить самому:

$startTime = mktime();
mysql_query('somequery', $db);
$endTime = mktime();
echo($endTime - $startTime); //Время, потраченное на операцию (включая и отработку PHP и скорость формирования результата мускулом) в ms.

Куда уж проще и надёжней?

[@crash]

Но тут, как вы заметили, мы прибавляем еще и время обработки пхп + доставка данных (если сервер не локальный). А сам мускул может дать время чистого запроса.

[@blockdog]

Ну, не будем кривить душой, представленный php код наиболее близок к тому, что покажет мускл.. тут нет, как вы выразились «обработки php» и «доставки данных».
Чтобы добавить это самое время, нужно изменить код до следующего (допустим, что выбираем одну строку в ассоциативный массив):

$startTime = mktime();
$result = mysql_query('somequery', $db);
$row = mysql_fetch_assoc($result);
$endTime = mktime();
echo($endTime - $startTime);

В этом случае первый выделенный фрагмент как раз будет обработкой php, а второй — доставкой данных.
Справедливости ради могу отметить, что в коде при выборке как раз используется мой вариант. Так что, все, что выводится внизу форумных движков — это как раз время с учетом обработки и доставки. Но, доставки не всегда, т.к. чаще всего код преобразуется до следующего:

$startTime = mktime();
$result = mysql_query('somequery', $db);
$endTime = mktime();
$row = mysql_fetch_assoc($result);
echo($endTime - $startTime);

т.е. доставка не входит в считаемое время..
Хотя, я лично видел несколько «общественных» скриптов, где запрос выполнялся два раза, одна раз как в первом варианте, а второй раз без подсчета времени. Т.е. выводились данные, никак не соответствующие реальности.

[@dRiveR_dLL]

Только не понимаю, почему вы используете функцию mktime(); ? Все таки измерять скорость выполнения запросов к БД измерять в секундах не очень правильно и microtime() будет более уместной.

[@smart]

Можно и так считать, вопрос в том, что дальше с этой цифрой делать? ;) Надо же все вместе собрать и проанализировать.

[@Nicholass]

Это ты с PHPinside ссылку взял? :)

[@blockdog]

Угу.

[@Nicholass]

И я свою про PHP/Java

[@smart]

Лог медленных запроов, безусловно, полезная штука. Но он не решает всех проблем - хотя бы потому, что минимальное время выполнения "медленного" запроса - 1 скеунда. Т.е. никак не заставишь mysql писать в него запросы, которые выполняются более 0.1 или 0.5 секунд. В то же время обычно наибольшее суммарное время приходится именно на такие запросы (а вове не на медленные). Обычно это довольно простые запросы, которые выполняются неэффективно из-за неправильно построенных индексов или неправильно формулированных запросов (и тем не менее, успевают отработать за секунду). Их можно (и нужно) отследить только аггрегируя полный лог запросов.

[@blockdog]

Действительно, long_query_time может быть только целочисленное.

[@debugman]

Всё так.

[@zerkms]

в mysqlperfomanceblog.com (на который я давал ссылку выше), помнится был патч для mysql, позволяющих рулить данным параметром с точностью до 0.001с.
прямую ссылку не дам, но точно было, полистай

[@cybrarian]

http://www.mysqlperformanceblog.com/2006…

[@sapper]

Извиняюсь за некропостинг.
Начиная с версии mysql 5.1.21 можно писать не целочисленное значение, типа long_query_time=0.5

[@smart]

Да, спасибо за уточнение. И тем не менее, это все равно не позволит выявить проблемы из-за миллионов очень коротких запросов.

[@Slash]

# вызвать mysqld со следующими параметрами:

–log-slow-queries[=/tmp/slow_queries.log]

опечатка. скобку уберите? :)

[@Slash]

оупс, извините, туплю :)

[@blockdog]

Это необязательный параметр.
Если он не указан, то лог будет сохраняться, если я не ошибаюсь в папке data/

[@WebByte]

Счастливые люди — медленные запросы 1–10 сек.
У меня в разряд медленных попадают запросы, которые фетчатся более 0.02 секунд. Для них ничего нет?

[@volerog]

В большинстве слуаев есть возможность воспользоваться профилировщиками со стороны клиента (правда возможно, придется написать собственный).

[@redhummer]

фетчатся или всёж "куэрятся"? )

[@WebByte]

Я сейчас говорю только про селекты, поэтому «фетчатся». То есть, само выполнение SELECT'а + вывод выборки. А UPDATE-INSERT «куэрятся» быстро, ибо OLTP-приложение. В тех, местах, где они выполняются долго, это оправдано и некритично. Скорость SELECT'ов критична у меня везде.

[@cybrarian]

http://www.mysqlperformanceblog.com/2006…

Но непонятно, зачем вы спрашиваете, если с MySQL уже не работаете.

[@g100m]

Postgres людям очень сильно рекомендую http://pgfouine.projects.postgresql.org/

[@kit]

То же на русском http://pgfouine.info/

[@unxed]

Хочу заметить, что если файл, в который будет писаться лог, класть не в /tmp, а, скажем, в /var/log, где он, по-моему, уместнее, то перед запуском mysqld файл уже должен существовать, а пользователь, от имени которого запускается mysqld - иметь к нему доступ на запись.

Добиться этого можно, например, так:

touch /var/log/mysql_slow_queries.log
chown mysql.mysql -R /var/log/mysql_slow_queries.log

[@shaliko]

Большое спасибо за статью!

[@Aldekein]

спасибо. авось пригодится... буду знать что такое есть.