Pull to refresh

Comments 57

Если вы нашли в тексте неточность, опечатку, или ошибку, пожалуйста, сообщите об этом в комментариях.
Не нужно бояться "долгих" запросов. Нужно дружиться с кешированием и InnoDB.
разве долгие запросы - не сигнал о том, что "что-то не в порядке с индесами и запросами"?
имхо цель кеширования - не залатать проблемы с неумением работать с индексами, а увеличить производительность и так уже оптимизированной бд
Не сигнал. А кто вообще кэшированием латает пробллемы с БД? Я говорю о тех случаях, когда медленных запросов не избежать, предполагая, что разработчик БД не ленив и потратил нужное время на её проектирование и осмысление.
имхо, данные советы отночятся как раз к этапу "разработчик БД не ленив и потратил нужное время на её проектирование и осмысление". т.е. в процессе "осмысления" подобные рекомендации ему могут пригодиться :)
Согласен, если долгие запросы выполняются с Вашего ведома - ничего страшного в этом нет. Но все же - бояться не нужно, нужно знать ;)
Да что Вы говорите? А может приведёте пример тестов, где ИнноДБ на селектах явно превосходит МайИсам?
Ну альтернативы-то есть всегда. Только не в рамках MySQL. Но на БД в основном с селектами MyISAM — вполне себе альтернатива для InnoDB
причем тут селекты, разве преимущество иннодб в первую очередь не в поддержке транзакций?
иногда они необходимы и тогда майизам теряет смысл.
Я говорю о поддержке транзакций (к скорости это отношения не имеет) и каскадных операциях (вот тут уже стоит задуматься).
InnoDB проиграет в скорости на примитивном селекте MyISAM, но когда понимаешь, что удаляя, либо изменяя некую строку в одной таблице, можно каскадно удалить/изменить данные в сколь угодно многих свзянных таблицах всего лишь одним запросом с гарантированной надёжностью, то становятся очевидными приимущества InnoDB.
Потому я и говорил выше InnoDB + вменяемое кэширование == Крест на MyISAM.
P.S. Я долго сидел на MyISAM и в действительности убеждён, что это самый быстрый тип БД MySQL. Но времена и требования от проекта к проекту меняются. Изменились и мои предпочтения.
Просто, IMHO, если вы работаете в MyISAM и у вас долго выполняются запросы, значит:
а. Вы просто напортачили в планировании БД
б. Вы не напортачили с БД, но просто такой рисковый парень, что готовы потерять данные, используя тип БД без поддержки транзакций.
Я вообще Мускул не использую, больно убогая БД.
И подходы к медленности запросов у нас с Вами разные
В последнее время не использую
Буду рад, если вы в пм отпишите, с чем работать стоит. Без иронии и шуток.
А можно мне продублировать, тоже интересно? :)
Те же Постгресс и Оракл. Транзакции у них, ессесн, есть, а возможности в плане выполнения выборок все ж помощнее Мускуловых. Про другие промышленные СУБД ничего сказать не могу — не использовал. Сравнение с Мускулом в рамках треда не распишу, не та тематика, да и статей на эту тему полно.
Оракл... Оно платное. Я видел как оно работает. Страшно. Я трудностей не боюсь, но симбиоза живого организма и компьютерной программы (да, программы) — опасаюсь (:
MySQL тоже платная для коммерческого использования (сюрприз, да?).

Для изучения Оракл вполне бесплатен и скачивается непосредственно с их сайта. Другое дело, что всякие патчи и апдейты недоступны. Но поиграться даже в серьёзные вещи вполне можно. И не так страшен Оракл, как его малюют. Хотя после Мускула первое время будет непривычно, да.
с каких это пор у мускула кроме платной поддержки появилась еще и платная эксплуатация !? всех хостеров арестовываем за контрафакт, ага?
Мне приводить здесь тексты лицензий или сами «асилите» в каких случаях используется GPL, а в каких коммерческая лицензия?
перечитал FAQ по лицензированию MySQL, так и не понял, где именно "MySQL тоже платная для коммерческого использования (сюрприз, да?)."

вы ничего не путаете? а то словами типа GPL вы бросаться научились, а ссылками нет. жаль ...
очень простой тест - 100 потоков делают SELECT, INSERT, UPDATE в одну таблицу.
в это случае MyISAM большинство времени будет простаивать на блокировке таблицы, а InnoDB в свою очередь будет простаивать только на блокировке строки или блокировки части индекса, в зависимости от того, какой уровень сериализации у вас.
Второй момент, чем плох MyISAM - часто бьются таблицы при большой нагрузке, что вообще неприемлемо для некоторых задач.
Я спрашивал про Селекты, а не еще и Инсерты / Апдейты.
Так то прекрасно знаю, что такое локи в MyISAM.
проглядел :) в случае когда данных больше чем кеша и фиксированный размер строки в myisam это верно. я никогда не делал тестов когда индексы/данные полностью помещаются в кеш mysql. подозреваю, что тогда разница не очень большой будет.
Надеюсь в следующей серии прочитать подробное описание EXPLAIN
При разработке ПО можно использовать встроенный в приложение профайлер БД. Например, в Zend Framework есть замечательный довольно гибкий профайлер.

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

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

Куда уж проще и надёжней?
Но тут, как вы заметили, мы прибавляем еще и время обработки пхп + доставка данных (если сервер не локальный). А сам мускул может дать время чистого запроса.
Ну, не будем кривить душой, представленный 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);

т.е. доставка не входит в считаемое время..
Хотя, я лично видел несколько «общественных» скриптов, где запрос выполнялся два раза, одна раз как в первом варианте, а второй раз без подсчета времени. Т.е. выводились данные, никак не соответствующие реальности.
Только не понимаю, почему вы используете функцию mktime(); ? Все таки измерять скорость выполнения запросов к БД измерять в секундах не очень правильно и microtime() будет более уместной.
Можно и так считать, вопрос в том, что дальше с этой цифрой делать? ;) Надо же все вместе собрать и проанализировать.
Лог медленных запроов, безусловно, полезная штука. Но он не решает всех проблем - хотя бы потому, что минимальное время выполнения "медленного" запроса - 1 скеунда. Т.е. никак не заставишь mysql писать в него запросы, которые выполняются более 0.1 или 0.5 секунд. В то же время обычно наибольшее суммарное время приходится именно на такие запросы (а вове не на медленные). Обычно это довольно простые запросы, которые выполняются неэффективно из-за неправильно построенных индексов или неправильно формулированных запросов (и тем не менее, успевают отработать за секунду). Их можно (и нужно) отследить только аггрегируя полный лог запросов.
Действительно, long_query_time может быть только целочисленное.
в mysqlperfomanceblog.com (на который я давал ссылку выше), помнится был патч для mysql, позволяющих рулить данным параметром с точностью до 0.001с.
прямую ссылку не дам, но точно было, полистай
Извиняюсь за некропостинг.
Начиная с версии mysql 5.1.21 можно писать не целочисленное значение, типа long_query_time=0.5
Да, спасибо за уточнение. И тем не менее, это все равно не позволит выявить проблемы из-за миллионов очень коротких запросов.
# вызвать mysqld со следующими параметрами:

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

опечатка. скобку уберите? :)
оупс, извините, туплю :)
Это необязательный параметр.
Если он не указан, то лог будет сохраняться, если я не ошибаюсь в папке data/
Счастливые люди — медленные запросы 1–10 сек.
У меня в разряд медленных попадают запросы, которые фетчатся более 0.02 секунд. Для них ничего нет?
В большинстве слуаев есть возможность воспользоваться профилировщиками со стороны клиента (правда возможно, придется написать собственный).
фетчатся или всёж "куэрятся"? )
Я сейчас говорю только про селекты, поэтому «фетчатся». То есть, само выполнение SELECT'а + вывод выборки. А UPDATE-INSERT «куэрятся» быстро, ибо OLTP-приложение. В тех, местах, где они выполняются долго, это оправдано и некритично. Скорость SELECT'ов критична у меня везде.
Хочу заметить, что если файл, в который будет писаться лог, класть не в /tmp, а, скажем, в /var/log, где он, по-моему, уместнее, то перед запуском mysqld файл уже должен существовать, а пользователь, от имени которого запускается mysqld - иметь к нему доступ на запись.

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

touch /var/log/mysql_slow_queries.log
chown mysql.mysql -R /var/log/mysql_slow_queries.log
спасибо. авось пригодится... буду знать что такое есть.
Sign up to leave a comment.

Articles