А поставьте на форум снова того человека, который в вашей разношерстной команде наемных писателей хабрадури читать умеет :)
Я же говорю : это логический баг парсинга данных от источника. Там негде сказать потреблять меньше. Можно конечно саму jvm ограничить, но тогда все падает (точнее впадает в постоянный GC), что ожидаемо.
а давайте вы сначала осмыслите что mysql вам предоставляет, а потом подумаете как в его терминах изложить вашу задачу?
что значит "подходит" ? нет такого понятия в субд. Есть операции точного сравнения = и поиска по маске like.
Вот и думайте. Может быть, вас устроит при вставке данных хранить корень фамилии (василь) в отдельном поле и по нему уже искать. Выделить корень фамилии - это уже совсем другая история и не обязательно напрягать mysql. Наверное есть парсеры всякие.
Andreyka, философия red5 заключена в методе реверсинжиниринга флеша. Собрались ентерпрайз-явапрограммеры и сказали "а давайте отреверсим протокол и напишем на яве супергиганта, как мы писали раньше для крутых поцанов". И пишут. Он 200 мб в нормальном режиме при старте жрет. Ентерпрайз. FMS жрет 10.
Как и следовало ожидать, отреверсили они кое-как. Буквально сейчас, я довольно стабильно ловлю баг при использовании официального консольного адобовского клиента - red5 неправильно парсит данные, валит кучу ошибок, жрет 1-3 гб памяти и чуть ли не вешает весь сервер. Ну куда это годится?
Решил пока отказаться от использования консольного клиента вещания, но мне это реально неудобно.
Не знаю в чем там дело, ведь спецификация RTMP уже давно опубликована, конечно после того как red5 дошел до состояния весьма серьезной замены FMS.
Надеюсь флеш-источники у них работают лучше и вам повезет больше. Я же не призываю ни в коем случае не использовать red5, но горя с ним хлебнуть есть где.
То есть все остальное вы уже дочитали? а там разве не написано, что индексы в mysql позволяют неплохо сокращать время поиска по известной левой части строки ? ну там где используется конструкция where name like 'васильев%'; ?
ok, пусть будет statistics, но вообще-то это какая-то начальная стадия. я не замечал чтобы mysql много времени тратил на нее. Документации по этим стадиям нет. вот, например, расширенное профилирование http://blogs.mysql.com/peterg/2008/11/06/show-profile-information_schemaprofiling/ показывает что statistics на стадии оптимизации выполняется.
Попробуйте профилировать запрос и проверить действительно ли statistics - очень медленная и длинная стадия исполнения запроса. Похоже, mysql эти ваши индексы лишние читает и пытается решить какой них лучше. Я бы их просто сократил до минимума и посмотрел бы что изменится.
В любом случае, возьмите за правило : индекс с cardinality меньше 1% - не нужен . Если при выборке эти поля важны, посмотрите какие еще поля используются в той же выборке и сделайте составной индекс.
Ну а вот эти вот мнения "да годами все работало! да ничего не меняли, а потом вдруг начало тормозить" - это постоянно бывает. По мере накопления данных наступает какой-нибудь критический момент и mysql может внезапно избрать другой план выполнения.
Red5, скажу я вам, типичное яваговно, но бесплатно лучше не найти.
Точно недавно. int не надо добавлять. к индексам напрямую это не относится. многое зависит от задачи.
Узнав расшифровку незнакомого термина, стоит погуглить, чтобы узнать типичные методы применения и специфику применения в mysql.
Недавно в отрасли ?
http://ru.wikipedia.org/wiki/%D0%98%D0%BD%D0%B4%D0%B5%D0%BA%D1%81_(%D0%B1%D0%B0%D0%B7%D1%8B_%D0%B4%D0%B0%D0%BD%D0%BD%D1%8B%D1%85)
я повторюсь :
DJ_AlieN,
пока вы не показали что нашли этот запрос.
Конечно, есть и другие способы заблокировать таблицу кроме запроса - какая-нибудь педально-ручная система сложных обновлений на уровне приложения может подать lock table и зависнуть, но это скорее редкость. Надо найти тот запрос.
Индексов, кстати дохрена. Так не делают. Да еще и с мощностью = 5 - вообще никуда не годится. Обновление такой таблицы на загруженном hdd может и правда растянуться на часы. Учтите, что mysql не использует несколько процессоров для одного запроса никогда. Фактически, у вас одноядерный ксеон.
Наверное и с остальными таблицами такая же история ? Вам, скорее нужен прикладной программист, который в курсе что такое составные индексы, да и как вообще все работает в mysql. Чистые админы понасоветуют тут.
При реально массивных обновлениях можно попробовать временно отключать индексы : alter table disable/enable keys - некоторые операции поразительно ускоряются.
Из всех Locked нужно выделить запрос который не Locked и работает с таблицей `cms_foto_obj`
он и тормозит. Если он написан безобразно, то не факт что innodb поможет - у нее ведь и свои минусы есть, которые могут перевесить небольшой выигрыш от отсутствия необходимости блокировать.
Но для начала можно попытаться перевести эту таблицу в innodb.
