Comments 18
Ваши манипуляции мне понятны, но статье явно не хватает выводов
Почему и зачем мне эти советы, какой прирост производительности?
Почему и зачем мне эти советы, какой прирост производительности?
Все замечания верные. Но если рассматривать все нюансы — здесь будет простыня, а я сторонник минимализма. Лучше рассматривать статью как набор подсказок. В конце концов у аудитории должно быть понимание зачем нужен каждый шаг и что в нём можно изменить конкретно для них.
Дело в том, что, не указывая деталей, почему вы решили, что это поможет, вы дискредитируете себя в первую очередь. Советы, в целом, не самые плохие, но явно не все нужно делать. Про query cache уже сказали, есть вопросы про buffer_pool_instances и про партишенинг. Вы меряли производительность при работе с партиционированными таблицами? Эта фича в мускуле появилась в мускуле относительно недавно и в интернете можно найти очень много ругани на счет деталей реализации. Я верю, что в вашем случае все нормально, но я бы точно не советовал бы другим людям использовать эту фичу бездумно.
Сжатые страницы, кстати, тоже далеко не идеально работает в innodb и имеют много багов, вплоть до порчи данных. Кейсы редкие, но обычно встречаются именно тогда, когда данных много и нагрузка высокая…
Кстати о кэше — чем лучше всё измерить? Всё измерение моих оптимизаций сводилось к тому, что на каждой страничке системы, выводящей журнал, статистику и прочее внизу счётчик времени выполнения. Если он уменьшился для типовых операций — значит хорошо. А он уменьшился, и заметно.
innodb_change_buffer_max_size=10; В CDR мы мало пишем и много читаем. Буфер на запись ставим небольшой.
так все же вставок или чтений?
Если основная нагрузка — вставки, предпочтительнее может оказаться myisam.
Sign up to leave a comment.
Оптимизация базы данных CDR в MySQL