pwlnw

Как-то ты неправильно понимаешь СУБД.

Если групп немного без тенденций к росту, можете изобразить ограничивающие VIEW и раздать доступ пользователям туда.

Другой способ — хранимые процедуры старательно проверяющие все параметры. Пользователями дают доступ к этим процедурам, а доступа к таблицам напрямую не дают.
Проблема в том, что в mysql эти вещи недостаточно полно и удобно реализованы.

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

Если групп немного без тенденций к росту, можете изобразить ограничивающие VIEW и раздать доступ пользователям туда.

Другой способ — хранимые процедуры старательно проверяющие все параметры. Пользователями дают доступ к этим процедурам, а доступа к таблицам напрямую не дают.
Проблема в том, что в mysql эти вещи недостаточно полно и удобно реализованы.

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

Вполне типично для VPS.
Вместо того чтобы тратить время на случайные флуктуации, собирайте статистику за день и ищите наиболее тормозящие запросы программой mysqlsla.

Конечно, 10 секунд это многовато, но у хостеров свое мнение.

>VPS
>падение производительности

Сопротивление бесполезно.
Но ты еще можешь пожаловаться хостеру.

Раз уж ты освоил обычную репликацию, то разберись тогда и с репликацией master-master. Поочередно на каждом сервере сделай ALTER. Во время работы ALTER направляй запросы на другой сервер.

>2gb ram, Intel® Atom(TM) CPU D510 @ 1.66GHz
>Сервак — боевой, простой — недопустим.

Не особо верится, кстати.

>Первые 1000 записей шустренько, потом все медленней, меeдленнней и меeеееeдленннннннней…

Напоминает поведение при длинных транзакциях. Может просто автокоммит делать?
Это просто догадка. Если не поможет, то вам придется исследовать досконально.

Однако, попробуй подцепить этот скрипт для mysql-proxy: github.com/clofresh/mysql-proxy-cache
разумеется он кеширует все игнорируя логику приложения.

Я плохо понимаю зачем может понадобиться такое решение.
Встроенным кешированием запросов можно управлять явно через ключевые слова SQL_CACHE и SQL_NO_CACHE.

«Прозрачное кеширование» есть в самом mysql.
Оно настолько хорошо и прозрачно работает, что ты про него даже не знаешь.
Проблема возникает тогда, когда нужно кеш инвалидировать. Например, обновление некоторых записей. Поэтому выдуманное тобой прозрачное кеширование вынуждено будет повторить поведение кеша mysql — удалить все запросы содержащие обновляемую таблицу. Ну и зачем писать то, что уже написано?

Отсюда вывод: если хочется что-то ускорить еще быстрее кеша mysql — кеширование не должно быть прозрачным. Для каждого оператора должно хотя бы указываться предположительное время жизни результата в кеше.

FLUSH TABLES WITH READ LOCK;
Только эта конструкция глобально блокирует все операции записи в файлы на сервере. SELECT-ы работают.

Не очень понятны предпосылки к такому решению. Почему бы не воспользоваться репликацией или простым дампом?

Хороший повод открыть для себя транзакции в СУБД.

1.844E+19 в таблице типа myisam.
У innodb сложнее найти, но есть ограничение на 64Тб на файл, а значит и на таблицу.

Только эти знания вам никакой практической пользы не принесут.

> Рейд держит нормальная железякя
>LSI
уже смешно. батарейки и памяти там ведь нет?

>RAID5
>innoDB
>утилизация винта — 15-20%
>innodb_flush_log_at_trx_commit = 2
>самый обычный запрос… ДВЕ секунды…

Запись в RAID5 уже по необходимым логическим операциям получается сложная, а в реализации LSI все обычно получается еще хуже. Как тут уже говорили, для баз данных предпочтительней RAID1,RAID10 и вариации.

Остается снизить интенсивность операций записи. Попробуйте в первую очередь
innodb_flush_log_at_trx_commit=0
innodb_support_xa=0
tmpdir = /tmp/ — перенесите в tmps

Во вторую очередь более опасные параметры:
innodb_doublewrite=0
delay_key_write=ALL
innodb_flush_method=nosync — вообще не знаю использует ли кто-то это. значение даже недокументировано, но кое-где можно найти его использование. если требования к производительности высокие и сервер не перегружается внезапно ( а с чего бы ему перегружаться в хорошем датацентре?), то можно использовать.

почитайте про каждый параметр, потому что такое изменение — компромисс между скоростью и надежностью хранения данных.

bin-log — точно знаете зачем он вам нужен?
query_cache_size = 0 — неужели он у вас вообще неэффективен? поставьте ну хотя бы 16Мб.
sort_buffer_size = 256M — с этим поосторожнее, он выделяется целиком в каждом обработчике вне зависимости от реальной потребности. При перегрузке сервера запросами возможно исчерпание памяти и убитие в первую очередь mysqld.