Я очень удивлен, что я не вижу ответа на этот вопрос ни на сайте, ни в документации MySQL (Раздел 5.2 Кажется, что ведение журнала хорошо освещено!)
Если я включаю бинлоги, я вижу небольшое снижение производительности (субъективно), чего следовало ожидать с небольшим дополнительным вводом-выводом, но когда я включаю общий журнал запросов, я вижу огромное снижение производительности (удвоение времени на выполнение запросов, или того хуже), намного превосходя то, что я вижу с помощью журналов. Конечно, теперь я регистрирую каждый 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 - если это один и тот же диск, вы будете все время читать и записывать в несколько мест, замедляя весь процесс.
Это верно, даже если это другой раздел на том же физическом диске.
Если ведение журнала ведется на другое устройство, это должно облегчить некоторые проблем с производительностью.