Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 57
Если вы нашли в тексте неточность, опечатку, или ошибку, пожалуйста, сообщите об этом в комментариях.
вот хорошая тема в продолжение http://www.mysqlperformanceblog.com/2007…
Не нужно бояться "долгих" запросов. Нужно дружиться с кешированием и InnoDB.
разве долгие запросы - не сигнал о том, что "что-то не в порядке с индесами и запросами"?
имхо цель кеширования - не залатать проблемы с неумением работать с индексами, а увеличить производительность и так уже оптимизированной бд
имхо цель кеширования - не залатать проблемы с неумением работать с индексами, а увеличить производительность и так уже оптимизированной бд
Согласен, если долгие запросы выполняются с Вашего ведома - ничего страшного в этом нет. Но все же - бояться не нужно, нужно знать ;)
Да что Вы говорите? А может приведёте пример тестов, где ИнноДБ на селектах явно превосходит МайИсам?
Иногда альтернативы InnoDB нет.
Я говорю о поддержке транзакций (к скорости это отношения не имеет) и каскадных операциях (вот тут уже стоит задуматься).
InnoDB проиграет в скорости на примитивном селекте MyISAM, но когда понимаешь, что удаляя, либо изменяя некую строку в одной таблице, можно каскадно удалить/изменить данные в сколь угодно многих свзянных таблицах всего лишь одним запросом с гарантированной надёжностью, то становятся очевидными приимущества InnoDB.
Потому я и говорил выше InnoDB + вменяемое кэширование == Крест на MyISAM.
P.S. Я долго сидел на MyISAM и в действительности убеждён, что это самый быстрый тип БД MySQL. Но времена и требования от проекта к проекту меняются. Изменились и мои предпочтения.
InnoDB проиграет в скорости на примитивном селекте MyISAM, но когда понимаешь, что удаляя, либо изменяя некую строку в одной таблице, можно каскадно удалить/изменить данные в сколь угодно многих свзянных таблицах всего лишь одним запросом с гарантированной надёжностью, то становятся очевидными приимущества InnoDB.
Потому я и говорил выше InnoDB + вменяемое кэширование == Крест на MyISAM.
P.S. Я долго сидел на MyISAM и в действительности убеждён, что это самый быстрый тип БД MySQL. Но времена и требования от проекта к проекту меняются. Изменились и мои предпочтения.
Просто, IMHO, если вы работаете в MyISAM и у вас долго выполняются запросы, значит:
а. Вы просто напортачили в планировании БД
б. Вы не напортачили с БД, но просто такой рисковый парень, что готовы потерять данные, используя тип БД без поддержки транзакций.
а. Вы просто напортачили в планировании БД
б. Вы не напортачили с БД, но просто такой рисковый парень, что готовы потерять данные, используя тип БД без поддержки транзакций.
Я вообще Мускул не использую, больно убогая БД.
И подходы к медленности запросов у нас с Вами разные
И подходы к медленности запросов у нас с Вами разные
В последнее время не использую
Буду рад, если вы в пм отпишите, с чем работать стоит. Без иронии и шуток.
А можно мне продублировать, тоже интересно? :)
Те же Постгресс и Оракл. Транзакции у них, ессесн, есть, а возможности в плане выполнения выборок все ж помощнее Мускуловых. Про другие промышленные СУБД ничего сказать не могу — не использовал. Сравнение с Мускулом в рамках треда не распишу, не та тематика, да и статей на эту тему полно.
Оракл... Оно платное. Я видел как оно работает. Страшно. Я трудностей не боюсь, но симбиоза живого организма и компьютерной программы (да, программы) — опасаюсь (:
MySQL тоже платная для коммерческого использования (сюрприз, да?).
Для изучения Оракл вполне бесплатен и скачивается непосредственно с их сайта. Другое дело, что всякие патчи и апдейты недоступны. Но поиграться даже в серьёзные вещи вполне можно. И не так страшен Оракл, как его малюют. Хотя после Мускула первое время будет непривычно, да.
Для изучения Оракл вполне бесплатен и скачивается непосредственно с их сайта. Другое дело, что всякие патчи и апдейты недоступны. Но поиграться даже в серьёзные вещи вполне можно. И не так страшен Оракл, как его малюют. Хотя после Мускула первое время будет непривычно, да.
очень простой тест - 100 потоков делают SELECT, INSERT, UPDATE в одну таблицу.
в это случае MyISAM большинство времени будет простаивать на блокировке таблицы, а InnoDB в свою очередь будет простаивать только на блокировке строки или блокировки части индекса, в зависимости от того, какой уровень сериализации у вас.
Второй момент, чем плох MyISAM - часто бьются таблицы при большой нагрузке, что вообще неприемлемо для некоторых задач.
в это случае MyISAM большинство времени будет простаивать на блокировке таблицы, а InnoDB в свою очередь будет простаивать только на блокировке строки или блокировки части индекса, в зависимости от того, какой уровень сериализации у вас.
Второй момент, чем плох MyISAM - часто бьются таблицы при большой нагрузке, что вообще неприемлемо для некоторых задач.
Надеюсь в следующей серии прочитать подробное описание EXPLAIN
При разработке ПО можно использовать встроенный в приложение профайлер БД. Например, в Zend Framework есть замечательный довольно гибкий профайлер.
Да вообще скорость выполнения любого запроса (пример PHP) можно замерить самому:
$startTime = mktime();
mysql_query('somequery', $db);
$endTime = mktime();
echo($endTime - $startTime); //Время, потраченное на операцию (включая и отработку PHP и скорость формирования результата мускулом) в ms.
Куда уж проще и надёжней?
$startTime = mktime();
mysql_query('somequery', $db);
$endTime = mktime();
echo($endTime - $startTime); //Время, потраченное на операцию (включая и отработку PHP и скорость формирования результата мускулом) в ms.
Куда уж проще и надёжней?
Но тут, как вы заметили, мы прибавляем еще и время обработки пхп + доставка данных (если сервер не локальный). А сам мускул может дать время чистого запроса.
Ну, не будем кривить душой, представленный php код наиболее близок к тому, что покажет мускл.. тут нет, как вы выразились «обработки 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);
т.е. доставка не входит в считаемое время..
Хотя, я лично видел несколько «общественных» скриптов, где запрос выполнялся два раза, одна раз как в первом варианте, а второй раз без подсчета времени. Т.е. выводились данные, никак не соответствующие реальности.
Можно и так считать, вопрос в том, что дальше с этой цифрой делать? ;) Надо же все вместе собрать и проанализировать.
Это ты с PHPinside ссылку взял? :)
Лог медленных запроов, безусловно, полезная штука. Но он не решает всех проблем - хотя бы потому, что минимальное время выполнения "медленного" запроса - 1 скеунда. Т.е. никак не заставишь mysql писать в него запросы, которые выполняются более 0.1 или 0.5 секунд. В то же время обычно наибольшее суммарное время приходится именно на такие запросы (а вове не на медленные). Обычно это довольно простые запросы, которые выполняются неэффективно из-за неправильно построенных индексов или неправильно формулированных запросов (и тем не менее, успевают отработать за секунду). Их можно (и нужно) отследить только аггрегируя полный лог запросов.
Действительно,
long_query_time может быть только целочисленное.
Всё так.
в mysqlperfomanceblog.com (на который я давал ссылку выше), помнится был патч для mysql, позволяющих рулить данным параметром с точностью до 0.001с.
прямую ссылку не дам, но точно было, полистай
прямую ссылку не дам, но точно было, полистай
Извиняюсь за некропостинг.
Начиная с версии mysql 5.1.21 можно писать не целочисленное значение, типа long_query_time=0.5
Начиная с версии mysql 5.1.21 можно писать не целочисленное значение, типа long_query_time=0.5
# вызвать mysqld со следующими параметрами:
–log-slow-queries[=/tmp/slow_queries.log]
опечатка. скобку уберите? :)
–log-slow-queries[=/tmp/slow_queries.log]
опечатка. скобку уберите? :)
Счастливые люди — медленные запросы 1–10 сек.
У меня в разряд медленных попадают запросы, которые фетчатся более 0.02 секунд. Для них ничего нет?
У меня в разряд медленных попадают запросы, которые фетчатся более 0.02 секунд. Для них ничего нет?
В большинстве слуаев есть возможность воспользоваться профилировщиками со стороны клиента (правда возможно, придется написать собственный).
фетчатся или всёж "куэрятся"? )
http://www.mysqlperformanceblog.com/2006…
Но непонятно, зачем вы спрашиваете, если с MySQL уже не работаете.
Но непонятно, зачем вы спрашиваете, если с MySQL уже не работаете.
Postgres людям очень сильно рекомендую http://pgfouine.projects.postgresql.org/
То же на русском http://pgfouine.info/
Хочу заметить, что если файл, в который будет писаться лог, класть не в /tmp, а, скажем, в /var/log, где он, по-моему, уместнее, то перед запуском mysqld файл уже должен существовать, а пользователь, от имени которого запускается mysqld - иметь к нему доступ на запись.
Добиться этого можно, например, так:
touch /var/log/mysql_slow_queries.log
chown mysql.mysql -R /var/log/mysql_slow_queries.log
Добиться этого можно, например, так:
touch /var/log/mysql_slow_queries.log
chown mysql.mysql -R /var/log/mysql_slow_queries.log
Большое спасибо за статью!
спасибо. авось пригодится... буду знать что такое есть.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как выявить медленные SQL запросы?