Доброго времени суток. Подскажите как уменьшить нагрузку на процессор.
Раз в минуту скрипт делает выборку заданий :

как только MySQL начинает обрабатывать этот запрос сервер застывает секунд на 5, такие провисания не приемлемы, в таблице около 30милионов записей.
Структура таблицы:


Подскажите как оптимизировать мускул чтобы он имел так сказать планку и выше не прыгал. Может что-нибудь в конфигах MySQL сервера оптимизировать ?
Буду благодарен за любые идеи.

Pentium® 4 CPU 2.40GHz
MySQL 5.0.67

что показывает explain? и, может, есть смысл проиндексировать поле status?

skyboy, explain говорит:



skyboy, сколько на это времени примерно уйдёт? Подозреваю что не мало.

прошло 2 часа, поле ещё индексируется =)

Что быстрее бы отрабатывало (выборка из базы), если для поля status использовать (имеет 3 состояния) :

• status tinyint(1) not null default 0,  key (status)
• status int(1) not null default 0,  key (status)
• status set('0','1','2') not null default 0, key (status)
• status tinyint(1) not null default 0,  key (status(1))
• status int(1) not null default 0,  key (status(1))
• status set('0','1','2') not null default 0, key (status(1))

практически пофиг.

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

включи в логах логировать запросы которые долго выполняются...

если фрейворк, то можно влючить отладку и смотреть в каких участках медленно выплняются действия

в сложно запросе очень часто можно сделать ошибку, где mysql будет грузить сильно CPU

подскажите как правильней будет перегнать данные в новую таблицу.

я точно не уверен. поиском найти не смог. может, кто-то ещё подскажет.

нашел. я дезинформировал тебя. это было на хабре. и идея не просто в создании копии таблицы, а в последующей подмене MYI-файлов. А затем REPAIR TABLE
Внимание: в той статье говорится о создании уникального индекса. Применимо ли указанное к неуникальному индексу - для меня загадка.
жаль, что без подмены файлов не обойдется :(

Дело в том что  отработал, но теперь база ведёт себя как-то не адекватно =( выполнение запроса  , вообще не выполняется, точнее мускул начинает обрабатывать этот запрос (видно через дерево процессов) но потом процесс пропадает а ответа нету =(

что делать ?

Добавлено через 4 минуты и 6 секунд
Запросы типа  отрабатывают на ура, в чем тут трабл =(

Добавлено через 6 минут и 23 секунды
explain говорит :

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

быстрее, после создания индекса?

skyboy, индекс около 4х часов создавался. Гораздо быстрее стало, раньше ~ 10 сек теперь меньше секунды =)

весьма вероятно, для запроса select count(*) from tasks where status='done', использование индекса происходит не на благо а во вред. А план показывает что индекс использвуется.
Если более 20% записей попадают под критерий status='done', то использование индекса для отбора по этому предикату, как правило, оказвается не эффективным. Если этот тот самый случай, лучше подсказать оптимизатору, что индекс использовать не стоит.



Это сообщение отредактировал(а) Zloxa - 6.8.2010, 10:46

Zloxa, действительно, игнорируя индекс запрос :

выполняется, хотя и не так быстро как хотелось бы.

было бы настораживающе странно, если бы 30млн записей пересчитались мгновенно.