Leave a comment

Comments 9

neretin October 4 2011, 12:42:38 UTC
- безусловное чтение это выборка всех записей что ли? это же беда-беда
- попробуйте использовать memory tables (или что-то вроде memcached, но это не уровень БД) для временных данных (скажем, хеши сессий)
- почитайте про особенности table engines - MyISAM, InnoDB и т.д.
- почитайте про типы индексов (Hash, BTree)

из лит-ры могу порекомендовать "High Perfomance Mysql" (O'Reily)

Reply

eking_go October 4 2011, 12:48:43 UTC
memory tables - да, знаю, использую иногда.

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

Книжку посмотрю, спасибо.

Reply

alexkuklin October 4 2011, 12:50:12 UTC
не просто High Perfromance Mysql, а вторую редакцию
http://shop.oreilly.com/product/9780596101718.do

Reply

neretin October 4 2011, 12:51:57 UTC
да :)
я сам всегда ищу последнюю редакцию книг, поэтому как-то не подумал уточнить.

Reply


svetasmirnova October 4 2011, 13:08:36 UTC
> В частности, Как определить, какие индексы нужны?

Тестировать. Взять запросы, которые у вас чаще всего выполняются, посмотреть как на них влияют индексы при помощи EXPLAIN. Начать с тех, которые находятся в slow query log

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

Reply

eking_go October 4 2011, 13:27:30 UTC
Спасибо.

Не всегда можно посмотреть slow query log, т.к. иногда так нагрузят БД, что вообще логи отключаешь, иначе дисковая умирает... Ну или так тормозит, что работать невозможно. (например - порезанная по ресурсам виртуалка) :(

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

Reply

svetasmirnova October 4 2011, 16:19:57 UTC
> Не всегда можно посмотреть slow query log, т.к. иногда так нагрузят БД, что вообще логи отключаешь, иначе дисковая умирает...

Поставьте большое long_query_time: больше умолчальных 10 секунд, много туда не запишется. А вообще он теперь динамический. Включите на небольшое время, посмотрите что там, оптимизируйте, дальше следующие.

> Как посмотреть список всех выполненных запросов отсортированных по частоте, скажем?

Если из slow log - то либо при помощи утилиты mysqldumpslow, либо перенаправив его в таблицу

> Или просто всех запросов, если мне код клиентского приложения не доступен?

Встроенное средство - general query log. Я почему его так легко советую: начиная с версии 5.1 он динамический, то есть его можно включить и выключить в любой момент. Плюс его можно перенаправить в табличку и потом сортировать её как любую другую.

Есть ещё решения, использующие proxy. В этом случае все запросы через него надо пропускать.

Reply


vitaly_il October 4 2011, 19:15:22 UTC
добавлю к вышесказанному:
- проверьте-настройте размеры буфферов и проч. параметры в my.conf
- сделайте один или несколько slave для чтения
- mysqlsla готовит отчет на базе slow (и/или general) с самыми тяжелыми запросами. для них и пробуйте индексы и т.д.

много полезного есть на http://www.mysqlperformanceblog.com/

Reply


as_pushkin_by October 4 2011, 21:11:51 UTC
- отталкиваться от задач
- не использовать триггеры и хранимые процедуры
- для больших выборок вместо многоэтажного JOIN делать выборки по ключу

Reply


Leave a comment

Up