Реєстрація шкодить продуктивності MySQL - але чому?

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

Якщо я вмикаю бінлоги, я бачу невеликий показник ефективності (суб'єктивно), якого слід очікувати з невеликим додатковим введенням, але коли я вмикаю загальний журнал запитів, я бачу величезне враження від продуктивності (вдвічі більше часу для запуску запитів, або ще гірше), що перевищує те, що я бачу у бінологах. Звичайно, я зараз реєструю кожен SELECT, а також кожне ОНОВЛЕННЯ / ВСТАВКА, але, інші демони записують кожен свій запит (Apache, Exim), не перемелюючись до зупинки.

Чи я просто бачу наслідки того, що вони близькі до "переломної точки" продуктивності, коли мова заходить про IO, чи є щось принципово важке в запитах реєстрації записів, через що це відбувається? Я хотів би мати можливість записувати всі запити, щоб полегшити розробку, але я не можу виправдати тип апаратного забезпечення, який, як нам здається, потребує відновлення продуктивності із загальним входом у систему запитів.

Я, звичайно, реєструю повільні запити, і там, якщо я відключу це, незначне поліпшення загального використання.

(Все це на Ubuntu 10.04 LTS, MySQLd 5.1.49, але дослідження говорять про це досить універсальне питання)

Загальні журнали запитів набагато більше IO, ніж двійкові журнали. Крім того, що більшість серверів SQL на 90% читає до 10% записів, двійкові журнали зберігаються у двійковому форматі, а не в простому тексті, де використовується менше місця на диску. (На скільки менше місця? Я не впевнений. Вибачте.)

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

Друга частина до цього полягає в тому, що в звичайному веб-додатку зазвичай є десятки запитів SQL, пов’язаних з однією сторінкою HTTP. Електронні листи, як правило, надходять у меншій кількості, ніж HTTP-запити. Ваш сервер MySQL, ймовірно, намагається ввійти набагато більше, ніж Apache або Exim.

Подивіться на розмір (нестиснений) ваших бінарних та загальних журналів MySQL та ваших журналів Apache та Exim наприкінці дня. Б'юсь об заклад, ви знайдете, що загальний журнал MySQL є найбільшим за коефіцієнтом не менше 5.

Щоб додати до наданої відповіді , ви також побачите хіт продуктивності, якщо ви входите на той самий пристрій, на якому зберігаються ваші сховища даних MySQL - якщо це один і той же диск, ви збираєтеся читати і записувати в кілька локацій весь час, сповільнюючи весь процес.

Це справедливо, навіть якщо це інший розділ на одному фізичному диску.

Якщо ведення журналу відбувається на іншому пристрої, це повинно полегшити деякі проблеми з продуктивністю.