Форум пользователей MySQL

По топорному пути оптимизации Вы уже почти прошли - настройки сервера, кэши, модификаторы к запросам, остался только один шаг - купить новое железо

Еще есть целый непройденный творческий путь оптимизации - переструктурировать базу и приложение

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

Всякое может быть. Скажем такая версия - при работе MySQL используется больше буферов, кэшей, они наполняются постепенно. У ОС не остается свободной памяти и она не может продолжать хранить данную таблицу в дисковом кэше.

Посту ап надо, как я понял)))

Возможно это совпадение, но когда я убил процессы апдейтов, инсерты сразу же получили доступ к таблице и отработали.

Текущая стата сервера:
Com_insert       14470600
Com_replace    24316180
Com_select        2299457
Com_update      1406775

Table_locks_immediate         36685557
Table_locks_waited                5843014

Много у меня реплейсов. Это нормальный подход или лучше использовать инсерты для новых записей и апдейты для существующих?

Ну и последний вопрос в этой теме.
Все расследования указывают на то, что проблема торможения в массовости апдейтов, по этому было решено вынести поля апдейтов в отдельную таблицу. Но вот сегодня я подумал... А ведь селекты используют эти поля в условии, а значит при джоине с новой таблицей результат окажется тот же (не будет доступа к таблице во время апдейтов), не так ли?

rgbeast написал:

Если вы априори не знаете что нужно выполнять UPDATE или INSERT, то использование REPLACE уместно.

В том-то и дело, что нужно будет сначала селект сделать, чтобы понять что нужно делать в дальнейшем - обновлять или вставлять. Ок, с этим понятно.

rgbeast написал:

Хорошо было бы разнести SELECT и UPDATE по разным таблицам. Если JOIN все равно использует другую таблицу, то польза от разделения ограничена.

Вот я тоже так подумал, ибо та таблица тоже может висеть.

Хотя вообще я разобрался с теми жёсткими апдейтами. Как оказалось, причина была на столько примитивна, что я даже не мог о ней предположить - в условии WHERE на первом месте использовались не проиндексированные поля Добавил индексы и за прошедшую ночь особого падения производительности не наблюдалось. По статистике за 20 часов работы сервера поступало 500 запросов в секунду, а проект работалд вполне вменяемо.

rgbeast написал:

Вам точно не поможет Innodb?

Главный минус InnoDB в чём? По-моему в более медленных селектах. По статистике, указанной выше, видно, что у меня сейчас селектов в 20 раз меньше, чем записей. Но проект доступен в сети всего одну неделю и уже сейчас имеет 500 хостов в день Естественно, это только начало, дальше посетителей будет всё больше и больше, потому и критична скорость выборки

Спасибо Вам за разъяснения и помощь в общем, такого ресурса я ждал в рунете много лет, и вот, он наконец-то появился

rgbeast написал:

варианты
1. запустить два mysqld на одной машине на разных портах и настроить репликацию - учитывайте, что она не будет синхронной, UPDATE слейва будет запаздывать и, кроме того, все UPDATE будут выполняться на обоих серверах

Могли бы разьяснить ситуацию с этим пуктом? Вот эти апдэйты на одной машине не сильно затупят сервер?
Хотим запустить слэйв с минимальным конфигом для "быстрых" бэкапов и с возможностью переключения на него мастера в случае чего.

Ребята, нада снова хелп разделили мы имеющуюся MyISAM таблицу на 2 InnoDB и 1 MyISAM. В запросах участвуют только первые две, тестирую производительность.

Без нагрузки запрос выполняется достаточно быстро - 1-1.5 секунды. В запросе джоинятся эти две таблички. Но вот повесил сейчас 10 потоков апдейтов на эти две таблицы и всё, время запроса в глубокой трещине - 50-130 секунд с теми же параметрами. На данный момент первая таблица имеет около 7к записей, а вторая около 1.7млн записей, что не так много для таких тормозов.

Подскажите, куда копать? Конфиги InnoDB не трогал и более того, в глаза не видел))