войти зарегистрироваться

MySQL whois

индекс
202,61

MySQL Profiler: простой и удобный инструмент профилирования запросов

Сегодня был неожиданно удивлен, какие удобные штуки таит в себе MySQL. ;-)

Хочу представить вашему вниманию фичу MySQL — профайлинг.
Появилась она начиная с версии 5.0.37.

Всего парой запросов можно узнать, какими запросами формируется страница (для веб-девелоперов)
и почему она тормозит.

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

Итак, как пользоваться:



mysql> set profiling=1;
mysql> select count(*) from comment;
mysql> select count(*) from message;
mysql> show profiles;

+----------+------------+------------------------------+
| Query_ID | Duration   | Query                        |
+----------+------------+------------------------------+
|        1 | 0.00012700 | select count(*) from comment |
|        2 | 0.00014200 | select count(*) from message |
+----------+------------+------------------------------+
2 rows in set (0.00 sec)


Вуаля! Все выполненные запросы за сессию с временем выполнения.

На мой взгляд очень просто и сверх-удобно.

Можно пойти дальше, и узнать подробно на что тратилось время по каждому запросу:

mysql> show profile for query 1;
+--------------------------------+----------+
| Status                         | Duration |
+--------------------------------+----------+
| starting                       | 0.000015 |
| checking query cache for query | 0.000021 |
| checking permissions           | 0.000003 |
| Opening tables                 | 0.000007 |
| System lock                    | 0.000004 |
| Table lock                     | 0.000023 |
| init                           | 0.000005 |
| optimizing                     | 0.000005 |
| executing                      | 0.000025 |
| end                            | 0.000003 |
| end                            | 0.000001 |
| query end                      | 0.000002 |
| storing result in query cache  | 0.000003 |
| freeing items                  | 0.000003 |
| closing tables                 | 0.000004 |
| logging slow query             | 0.000002 |
| cleaning up                    | 0.000001 |
+--------------------------------+----------+
17 rows in set (0.00 sec)


Подробнее о профайлинге в статье: Using the New MySQL Query Profiler

Upd: как точно подметил zayceslavshow profiles по умолчанию показывает профили для 15 запросов. Кол-во запрсов можно увеличить с помощью параметра profiling_history_size, но не более чем до 100.

mysql> set profiling=1;
mysql> set profiling_history_size=100;


PS: это мой первый пост, прошу не судить строго
+118
23 сентября 2009, 19:50
agorlov

комментарии (49)

    • nooze
    • nooze
    • 23 сентября 2009, 20:04
    • #
      • –3
    Да, mysql очень штука не простая. Меня больше всего радуют люди, которые говорят что MSSQL намного круче MySQL потому что там мол интерфейс и много инструментов а в mysql «ни хрена же нет, только запросы писать можно!»
    • Ну я бы сказал по другому, mssql круче, но для чего? Для обычных сайтов с малым кол-во посещений нет разницы какая субд, а вот при больших нагрузках и специфических задачах, тут уже нужно смотреть. У самого в проекте стоит mysql-кластер и жалоб никаких нет.
      • Само сравнение оставим в покое, я говорю о доводах — типа консольная субд ущербна по определению
        • В таком ракурсе согласен, данное утверждение просто смешное.
        • А чем отличается, как вы говорите «консольная субд», от субд, которая запускается в винде в виде «сервиса»? о_О
          Субд и все эти примочки в виде ГУИ — абсолютно разные вещи…
          Для мускуля тоже имеются ГУИ…
          • Я то знаю, но почему-то некоторые думают иначе
          • Я вот работаю в основном с MSSQL и очень люблю её за SQL Profiler, Query Analyzer, Management Studio и другие фичи. Когда пришлось работать с MySQL начал искать схожие по удобству, проработанности и функционалу утилиты для мускула, ведь «Для мускуля тоже имеются ГУИ». Боюсь вас разочаровать — ничего сравнимого с утилитами от мелкомягких для MySQL нету.
            И не надо меня попрекать, что я гонусь за GUI. Просто GUI в MSSQL позволяет мне сделать и оттестировать гораздо больший объем работы и сделать это на более качественном уровне.

            И сразу предостерегу от высокомерного «нам GUI не нужен» — тут в недавнем топике уже выяснили, что большая часть веб-разработчиков так и не удосужились освоить язык SQL на уровне, превосходящем простые запросы (к слову о HAVING ))) и имеют весьма туманное представление например о написании и отладке хранимых процедур.

            Хочу заметить, что я не перестаю удивляться отсутствию многофункциональных систем разработки и отладки для MySQL — даже для вполне себе бесплатного Firebird можно найти хорошие коммерческие программы управления базами данных.
            • раскрыть комментарий
              • navicat по мне удобнее аналогов. Для меня образец хорошего гуи для базы данных.
            • EMS, dbForge
              • Ага, спасибо, буду смотреть. EMS на скриншоте и по описанию выглядит неплохо, не попадался почему-то он мне в моих поисках, так что может я и поторопился… Тогда примите извинения за необоснованный наезд. ;)
                • я бы порекомендовал таки познакомиться вначале с dbForge. потому как инструмент мало того, что функциональнее EMS, так ещё и бесплатный.
                  • а есть что нибудь подобное для линукса? спасибо
                    • EMS вполне бегает под wine.
                      Нативных инструментов не знаю :-(
                  • Это то и пугает. Несколько бесплатных менеджеров для MySQL, которые я использовал (не вспомню уже названия) не отличались особой стабильностью.
                    • PMA + консоль :-)
            • Мне например, такой SQL pofiler, как в MySQL удобнее, чем ГУИшный, я могу в своем мини-фреймворке получить эти данные и вывести их тут же. под страницей. Могу скриптом их анализировать. А кнопки тыкать мне неохота (к тому же у всяких ГуИ для СУБД обычно скучный интерфейс, уснуть можно).

              И вообще, зачем БД GUI? Она должна запросы выполнять.
              • У нас подразделение, которое занимается разработкой на ASP.NET, большую часть времени проводит в Microsoft SQL Management Studio, так как вся бизнес логика основана на хранимых процедурах.
                • Вам никто не сообрал что хранение бизнес логики в процедурах некошерно?
                  • Там скорее всего не сама бизнес логика, а та ее часть, что должна работать на базе. Т.е. вместо query = «SELECT * FROM tblANYTHING» в коде стоит вызов хранимой процедуры через какой-то из connection objects, а уже в самой процедуре написано SELECT a, b, c FROM tblANYTHING
              • И? MS SQL точно также умеет отдавать данные профайлера с помощью простых запросов, и уж если тебя SQL Profiler не устраивает, так ради бога, выводи ты профайл хоть в текстовик, хоть в xml, хоть на лету считай, как уж тебе захочется. Не надо думать что MS SQL не умеет что-то, что можно сделать в MySQL.
            • SQLyog — www.webyog.com/en/index.php
              • Особенно вот эта таблица порадовала: www.webyog.com/en/sqlyog_feature_matrix.php

                Такое ощущение, что Community Edition ничего другого не делает, кроме показа баннеров :)
      • Расскажите как сделали кластер из mysql?
        • К сожалению поднимал кластер не я
    • Спорный вопрос, графическими инструментами не так часто приходится для MSSQL пользоваться, но вот в моем случае, тестировался MySQL и MSSQL для использования для сервера приложений, при их возможностях работы с большими объемами данных и сложными выборками, победил MSSQL, но вот для сайта был все же MySQL выбран.
  • все хорошо кроме одного, я не могу из одной сессии профилировать другую, т.е. реально мне нужно в коде прописать включение, выключение и в конце дамп вывода в какой-то файл — это не удобно, если чисто посмотреть запросы то тут удобнее mysql_proxy — ничего не надо менять в проекте (ну только порт)
    • Конкретную сессию вылавливать очень сложно, т.к. средняя сессия работы с БД у нас длится в среднем меньше 0.2секунды

      Для нас гораздо удобнее смотреть, по факту загрузки определенной страницы — чем она генерится.

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

      я наткнулся на этот профайлер, когда мы думали как сделать вывод всех запросов в консоль FireBug (через firephp)… сначала начлали писать враппер вокруг класса доступа к БД…

      но когда узнали про эту фичу — добавили два фрагмента кода, в самом начале программы, при подключении к БД, и в самом конце дампим в консоль,

      при этом не нагружается код дополнительными подсчетами времени на каждый запрос, это за нас делает СУБД. код в итоге получился компактнее.

  • В phpMyAdmin это тоже вроде как давно есть:

    Free Image Hosting at www.ImageShack.us
    • ток загнется ведь phpMyAdmin на больших объемах базы в которой не одна сотня таблиц
      • На больших обьемах как раз самое то в консоле, а на серваке GUI ненужен в принципе
  • Большое спасибо всем, что поддержали мой пост и меня :)
  • интересно. возьму на заметку.

    зы. вот же косяконул, забыл добавить в свой первый пост такой PS.
    жду теперь, может нло подсобит ))
  • завтра тете преподу по бд расскажу, пусть знает)
  • Очень, очень и очень полезно. Теперь будет еще проще отлаживать запросы, особенно в неизвестных CMS и прочих чужих сайтах.
  • Say «wellcome to my life» to dtrace
    (http://mysqldatabaseadministration.blogspot.com/2007/05/dtrace-and-mysql-1.html)
    • реально первый раз вижу когда плюют в карму кода дается линк на РЕАЛЬНо полезный продукт для работы с профилированием. к тому же дается линк на топики посвященные профилированию мускула…

      хабр не тот… =(
      • просто видимо пост неудачный выбран… с первого взгляда непонятно, что за «пробы» такие и зачем они нужны, что такое за dtrace и т.д.
      • Написали бы нормально, что это за зверь и с чем его едят, получили бы желанные плюсы. Правда не от меня. :)
  • >какими запросами формируется страница (для веб-девелоперов)
    и почему она тормозит
    Позанудю: почему страница «тормозит» расскажет, скорее, EXPLAIN. А профайлер покажет как она тормозит.
    Стоит упомянуть неудобство: show profile показывает профили максимум для 100 запросов :(
    • а куда вам больше-то?
      • Была необходимость.
        • если использовать грамотную обертку над мускулом, то каждую сотню запросов можно включать-выключать профайлинг для составления общего отчета
    • спасибо, добавил в пост
  • Классно! Жаль, ничего настолько удобного для Postgres'а нет. Может быть, кто-то знает для Postgres альтернативу (кроме pgFouine)?
  • Профайлинг уже описывали довольно подробно:

    habrahabr.ru/blogs/mysql/39818/
  • «о сколько нам открытий чудных...»
    спасибо за статью) как раз сейчас есть где её применить
    • barb
    • barb
    • 24 сентября 2009, 17:57
    • #
      • 0
    Век живи — век учись. Спасибо!
  • Сегодня использовал эту профилировку. Может это баг, может фича, но в выводе show profiles; вижу кусок запроса, а не весь. И фиг знает, почему он его отрезает :-(
    Может у кого есть идеи по этому поводу? А то смысла в этом профилировщике вообще нет.
Только авторизованные пользователи могут оставлять комментарии. Авторизуйтесь, пожалуйста.