Ведение журнала снижает производительность MySQL, но почему?

Я весьма удивлен тем, что нигде не вижу ответа на этот вопрос ни на сайте, ни в документации по MySQL ( кажется, что в разделе 5.2 все остальное хорошо освещено!)

Если я включаю binlogs, я вижу небольшое снижение производительности (субъективно), которое следует ожидать с небольшим дополнительным вводом-выводом - но когда я включаю общий журнал запросов, я вижу огромный удар по производительности (вдвое больше времени для выполнения запросов, или хуже), намного больше того, что я вижу с бинлогами. Конечно, теперь я регистрирую каждый SELECT, а также каждый UPDATE / INSERT, но другие демоны записывают каждый свой запрос (Apache, Exim) без остановки.

Я просто вижу эффект от приближения к «переломному моменту» производительности, когда дело доходит до ввода-вывода, или есть что-то принципиально сложное в протоколировании запросов, которое вызывает это? Мне бы хотелось иметь возможность регистрировать все запросы, чтобы упростить разработку, но я не могу обосновать тип оборудования, на котором, как нам кажется, нам нужно было бы восстанавливать производительность при общем входе в систему запросов.

Я, конечно, регистрирую медленные запросы, и общее отключение незначительно улучшается, если я отключаю это.

(Все это на Ubuntu 10.04 LTS, MySQLd 5.1.49, но исследования показывают, что это довольно универсальная проблема)

Общие журналы запросов намного больше операций ввода-вывода, чем двоичные журналы. Помимо того факта, что большинство SQL-серверов читают с 90% до 10%, двоичные журналы хранятся в двоичном формате, а не в виде обычного текста, который использует меньше дискового пространства. (Насколько меньше места? Я не уверен. Извините.)

Существует два аспекта, по которым Apache и Exim могут записывать каждый запрос без значительного снижения производительности. Во-первых, они фиксируют факт выполнения запроса, но то, что они помещают в журнал, обычно значительно меньше, чем фактический запрос. HTTP-запрос часто вдвое больше строки, идущей в журнале, и даже короткое текстовое электронное письмо в 10 или 20 раз больше, чем сопровождающая его строка журнала. Письмо с вложением размером 10 МБ будет содержать только несколько строк, записанных в журнале.

Вторая часть этого заключается в том, что в обычном веб-приложении обычно есть десятки запросов SQL, связанных с одной страницей HTTP. Электронные письма, как правило, приходят в меньшем количестве, чем HTTP-запросы. Ваш сервер MySQL, вероятно, пытается войти намного больше, чем Apache или Exim.

Посмотрите на размер (несжатый) ваших двоичных и общих журналов MySQL, а также журналов Apache и Exim в конце дня. Готов поспорить, вы найдете общий журнал MySQL как минимум в 5 раз.

Чтобы добавить к предоставленному ответу , вы также увидите снижение производительности, если вы входите в систему на том же устройстве, на котором находятся ваши хранилища данных MySQL - если это один и тот же диск, вы будете выполнять чтение и запись в нескольких местах. все время замедляя весь процесс.

Это верно, даже если это другой раздел на том же физическом диске.

Если ведение журнала происходит на другом устройстве, это должно устранить некоторые проблемы с производительностью.