forum.lissyara.su

Мужики, помогите разобраться.
Есть MySQL 5.5.29 на FreeBSD 8.3 amd64
Есть таблица Простейшая таблица в которой все поля индексы и к тому же записей в таблице менее 500 (не тысяч).
Так вот в логе медленных запросов (я поставил порог 1 сек) показывает такой запрос: Также тормозит запрос из таблицы где 5 тыс. записей и идёт UPDATE sessDate=$time WHERE is=$id (т.е. вообще по первичному ключу)
При этом на этом сервере выполняются гораздо более сложные запросы постоянно, вложенные запросы с массой объединений и т.п.
Подскажите куда копнуть?

Пользовать SSD диск.

Использовать SSD диск для базы в 30мб с одновременным обслуживанием не более 10 пользователей?
У вас на работе похоже все проблемы решаются исключительно вливанием денег а не устранением проблем в конфигурации.

Тёмный писал(а):Использовать SSD диск для базы в 30мб с одновременным обслуживанием не более 10 пользователей?

Если ваша субд генерит больше запросов чем может обработать HDD и время отклика критично, то да - нужен SSD
Да и когда UPDATE была быстрой операцией то..

У вас на работе похоже все проблемы решаются исключительно вливанием денег а не устранением проблем в конфигурации.

да вся индустрия ПО так работает..

Тёмный писал(а):Использовать SSD диск для базы в 30мб с одновременным обслуживанием не более 10 пользователей?
У вас на работе похоже все проблемы решаются исключительно вливанием денег а не устранением проблем в конфигурации.

Надо смотреть план запроса, кроме того, индексы надо выбирать с головой, а не как погодя, если у вас поле в таблице имеет значения 0 или 1, то индекс на это поле будет только тормозить, вполне возможно вам надо переставить поля в where и использовать < вместо =...

Спасибо за наводки. Добавил индексов, порылся с EXPLAIN, решил тормоза.
А по поводу SSD в моём случае (200 тыс. строк в БД, 10 пользователей, 40 запросов в сек), ну реально ребята это сатаной по воробьям стрелять. Эффективно но накладно.

snorlov писал(а):Надо смотреть план запроса, кроме того, индексы надо выбирать с головой, а не как погодя, если у вас поле в таблице имеет значения 0 или 1, то индекс на это поле будет только тормозить, вполне возможно вам надо переставить поля в where и использовать < вместо =...

А можно этот момент мне разъяснить? В смысле у меня полей-флагов с вариантами значений 0 или 1 много и я их индексами делаю, а ты говоришь это скорей вредно чем полезно.
Можешь кинуть ссылку чтобы почитать почему это вредно, только желательно не на всю документацию по MySQL Ну или так, на пальцах своими словами объясни пожалуйста.

Ну а чего тут обьяснять, индекс по существу дополнительная таблица, в случае малых значений, точнее малого изменения поля (2-а значения или к примеру 3-и) у тебя нет выигрыша к выборке, по существу вместо полного скана по таблице, ты делаешь почти полный скан по индексу, выбирая из него id и по этому id берешь данные из основной. Другое дело если индекс строишь по 2-м и более полям. Понятно также, что выборка по больше/меньше с вариантами 0/1 срабатывает быстрее чем равно. Ссылок к сожалению не дам, они у меня все старые, да и практически уже убраны поскольку этот вопрос очень хорошо обсасывался лет 10-ть назад, когда началось активное применение у нас sql-серверов...

Спасибо за помощь и разъяснения!

Не совсем так. Вопрос не в количестве значений поля (0 /1 или много разных), а в количестве строк, удовлетворяющих запросу.
Если выборка вынимает половину всех строк из таблицы, то индекс бесполезен. А если выборка вынимает только 10% строк, то индекс полезен даже по флагу.
Вот, например, тут -
http://www.mysqlperformanceblog.com/200 ... re-column/

Тёмный писал(а):Спасибо за наводки. Добавил индексов, порылся с EXPLAIN, решил тормоза.
А по поводу SSD в моём случае (200 тыс. строк в БД, 10 пользователей, 40 запросов в сек), ну реально ребята это сатаной по воробьям стрелять. Эффективно но накладно.

Дык, какой вопрос - такой ответ.

А что за железо то???