Форум MySQL

Есть БД mySQL довольно объёмная. И недавно стала появляться проблема. База работает в штатном режиме, всё нормально, но одна таблица вешается. Т.е. просто не открывается, т.е. запрос типа "SELECT * FROM table" выполняется бесконечно долго. А спустя некоторк время, всё приходит в норму.
Что это может быть и как это лечиться?

Попробуйте выполнить команду:

optimize table <имя таблицы>;

Сообщите также объём, какой занимает таблица table?

884 Кб на данный момент.
Optimize делал.
последние 3 дня вроде нормально работает.
Если повториться подниму тему.

Ну вот собственно и поднимаю :(((
Чё это может быть за фигня?

А таблица для чего используется? Какая нагрузка? Это на сервере происходит или на локальной машине? Какая версия MySQL? Вообщем нужно больше подробностей :)))

Таблица с данными о клиентах. Около 20000 строк. Нагрузка на сайт около 200000 хитов в сутки. Как посчитать нагрузку на конкретную таблицу я не знаю :(
Версия mysql - 4.0.24
Скажу любые подробности,которые будут нужны... кроме паролей ессно :)

Нагрузка в основном какая - SELECT-запросы или INSERT, UPDATE или DELETE. 200 000 хитов - это не хило, но объём достаточно мальнький - машина должна летать. Это выделенный сервер или хостинг. Если сервер свой какие характеристики и что в my.ini (сколько памяти выделено под MySQL) какая структура таблицы (какие поля проиндексированы)?

Это хостинг, но хостинг люксовый. Не более 2-3 сайтов на серваке. В основном используются запросы типа select.
Самое интересное что хостеры тоже голову ломают что это может быть.
Они подозревают что это какой-то запрос так грузит. Но я думал что в этом случае вешается вся база а не одна таблица. Вся база раньше часто падала. Потом прооптимизировал запросы,всё встало в норму.
Как в таком случае поступить и какие есть средства диагностики подобных болезней.
Они собирались лог запросов включить, но надолго говорят его нельзя оставлять, иначе он махом сожрёт весь диск. Но в том то и дело что переодичности не наблюдается :(((

Спросите их сколько памяти выделено под key_buffer_size и какова величина max_connections и каково значение статусной переменной Max used connections?

Можете ли вы посмотреть результирующую таблицу SHOW PROCESSLIST? Мониторить состояние дел всех удобнее по ней.

Пусть включат лучше журнал медленных запросов, не забыв при этом установить системной переменной long_query_time значение больше 0, скажем секунд 5-10.

Я эти переменные и сам могу посмотреть через mysql front. Это плохо в плане безопасности?
key_buffer_size = 8388600
max_connections = 500
max_user_connections = 0
И значение long_query_time щас стоит 10.
show processlist сделал.
Там постоянно висит одна строчка с коммандой sleep и time 6872 это что значит?
И как по этому листу оценивать? На что обращать внимание? И мне кажется в моменты подвисания эта команда не сработает... Или я не прав?

>key_buffer_size = 8388600
Никуда не годится - 8Мб под ключи? Сколько памяти на сервере?

>Там постоянно висит одна строчка с коммандой sleep и time 6872 это что значит?
В "SQL-запрос" что? Просто убейте этот процесс - если процесс выполняется два часа и при этом спит, да к тому же не является репликационным - ничего полезного не делает.

А что значит sleep в command и Locked в поле Info (где текст запроса появляется)?

Теперь блин два запроса sleep висят а в поле "SQL запрос" ничего... Как определить что это?

sleep - это ожидание команд от клиента, так бывает если остаются висеть не закрытые соединения, например, если используется функция mysql_pconnect(). Но дело вряд ли в них...

>max_user_connections = 0
Выполните SHOW STATUS и посмотрите значение Max_used_connetions

>И как по этому листу оценивать?
Обычно запросы выполняются так быстро, что вы в этом списке не увидите ничего - если вы начинаете видеть 5-10 запросов (не sleep) - сервер начинает вешаться. Вообще, конечно нужно смотреть журнал медленных запросов.

PS Первое что нужно сделать, это увеличить key_buffer_size - эта переменная должна занимать четверть памяти сервера, а не 8 Мб.

И снова та же проблема.
Мне вот интересно. Сейчас у меня висит куча Locked запросов в show processlist
Но при этом другие запросы не содержащие таблицы которые в Locked запросах выполняются очень шустро. Почему так?
Таблицы могут блокироваться по отдельности?
Есть какое-нить средство чтобы принудительно убить процесс?
Может ли хостер выставить какой-нить параметр чтобы такие зависшие запросы убивались по тайм ауту?

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