Грубо говоря кэш работает как простое key-value хранилище.
Key — хэш от самого запроса. Абстрактно md5($query), т.е. «SELECT * FROM table WHERE id = 1 AND id2 = 2» и «SELECT * FROM table WHERE id2 = 2 AND id=1» 2 разных хэша.
Value — массив, в котором сам результат, таблицы которые участвовали в запросе, etc. Для SELECT запроса генерируется хэш, быстро находится результат и возвращается. Сложность операции — O(1). Для INSERT/DELETE/UPDATE мускул проходит по всему хранилищу кэша. Находятся кэши, в которых участвует эта таблица и удаляется. И это для каждого(!) INSERT/DELETE/UPDATE.
Что лучше сканить? 10 мб или 1гб?
Скажем так — это не очевидно. Ситуации бывают разные. Например БД один раз в сутки генерится, после чего только читается клиентами (реальная задача). Сама база 10-20Гб. Причем кэш используется очень активно. Имеет ли смысл его размер в 20Мб?
Из поста: Каждая аппликация уникальная и сервер надо настраивать под конкретные нужды (ваш КО)
В вашем случае кэш выгоден. В обычном веб-приложении, которое юзает какой-нибудь active record, когда идентичность сгенерированного запроса не гарантировано — кэш зло.
Опция правильно называется «innodb_flush_log_at_trx_commit».
Можно ещё было написать, что если у RAID-контроллера нет батарейки, но включён write-back, то можно получить fail.
Немного неправильно сказал…
Суть такая: включая эту опцию, мы получаем некий write-back, но в контроллере есть батарейка, а в нашем случае данные при отключении электричества могут потеряться.
«Производительность MySQL» в Киеве, 22.09.2009