Які параметри конфігурації для MySQL забезпечують найбільші покращення швидкості?

Які параметри конфігурації для MySQL забезпечують найбільші покращення швидкості?

Мене цікавить фактичне вдосконалення файлу конфігурації, типи таблиць, налаштування обладнання, реплікація тощо. Все, крім структури запитів та структури таблиць (їх легко знайти на веб-сайті та переповнення стека). Чи такі речі, як налаштування кешу запитів, дали найбільшу швидкість? Як щодо накопичувачів; краще мати його на зовнішньому RAID або внутрішньому? Чи дала вам реплікація кращу продуктивність, особливо з читанням великих запитів?

Які ще налаштування / зміни ви зробили, щоб покращити продуктивність MySQL?

Примітка. Я розумію, що це дуже залежить від використання (тобто невеликий веб-сайт проти сховища даних), але, як я думаю, більшість з нас, ймовірно, працює на різних сайтах / системах, добре знати різноманітні методи, які можуть застосовуватися до різних ситуацій. Також, я думаю, деякі методи можна переносити між ситуаціями.

Ось мої рекомендації (ваша мінливість може відрізнятися)

• Використовуйте апаратний RAID. Це суперечить моїм рекомендаціям використовувати програмний RAID в інших посадах, однак це специфічна ситуація, коли потрібно апаратну RAID-карту. Зокрема, ви хочете, щоб NVRAM на базі батареї підтримував батарею на RAID-картці, щоб скоротити час на запуск файлу журналу fsync на диск.
• Використовуйте ТОЛЬКІ томи RAID 1 або RAID 10. Вартість записів на RAID 5 або 6 занадто висока, щоб допустити змішане навантаження для читання / запису.
• Використовуйте окремі LUN для томів даних, журналів та tmp. Усі вони повинні бути окремими від ОС та замінювати обсяги.
• Використовуйте InnoDB .
• Використовуйте innodb_file_per_table
• Використовуйте 64-бітну ОС
• Встановіть пул буфера InnoDB в розмірі ~ 80% доступної оперативної пам’яті
• Встановіть файли журналів на 1/4 розміру буферного пулу, ви маєте від 2 до 4 файлів журналів. Більші файли журналів означають повільніше час відключення та відновлення, але дозволяють швидше відновити великі скиди баз даних.
• log_slow_queries, log-queries-not-use-indexes, set-variable = long_query_time = 1, досліджуйте кожен запит у цьому журналі, переробляйте схему, щоб уникнути сканування таблиць та таблиць tmp, коли це можливо.

Ще раз Дейв Чейні справді вибив його з парку. Я дійсно не можу нічого додати до його відповіді на ваше запитання. Однак я хотів би зазначити те, про що ви не питали. Як мене багато років тому навчали Джеремі Заводний та Пітер Зайцев, ваша рентабельність інвестицій за час, витрачений на відстеження та оптимізацію поганих запитів, виконає рентабельність інвестицій за час, витрачений на внесення змін у конфігурацію в 10 разів. Звичайно, ви не хочете мати погану конфігурацію, неправильну настройку RAID або недостатню оперативну пам’ять. Але, серед відмінних і навіть незначних, погані запити MySQL DBA (зазвичай від розробників / фреймворків, а не DBA) є хронічним станом, коли погана конфігурація є витривалою .

(Я копав ті прикметники на деякий час і досі не задоволений тими, які я вибрав.)

Я хотів би ще раз наголосити, що якщо ваші розробники використовують ORM, подібний звичайним у таких рамках, як Ruby on Rails та Django, ви дійсно повинні відстежувати запити, які потрапляють у вашу БД. Коли розробники перестають думати про SQL і дозволяють БД абстрагуватися, це дуже неприємно. Я люблю дві рамки, про які я щойно згадував. (Не голосуйте за те, що їх погано вичісують.) Це просто робить Query Sleuthing дуже важливим. (Читайте: безпека роботи)

Ще небагато речей (про які не було сказано у відповіді Дейва Чейні)

• Спробуйте встановити innodb_flush_method на O_DIRECT, щоб уникнути подвійного буферизації даних. Уникайте цього, якщо на вашій RAID-картці немає кешованого резервного керування або ваші дані перебувають на SAN.

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

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

• Залежно від запуску програм, ви можете змінити рівень ізоляції за замовчуванням. За замовчуванням - REPEATABLE_READ, але READ_COMMITTED може покращити ефективність

• Якщо ваші висловлювання в основному є ОНОВЛЕННЯМИ і ВИДАЛЕНО, тоді ви можете спробувати прогрунтувати кеш на підлеглий, виконавши SELECT-запит, який повертає набір результатів, який слід змінити. Перевірте інструмент mk-slave-prefetch , який зробить це за вас

• Погляньте на інші двигуни зберігання даних, окрім MyISAM та InnoDB

Про апаратне забезпечення нічого не можна сказати, але ви можете спробувати http://blog.mysqltuner.com . Це сценарій Perl, який аналізує ваші налаштування MySQL.

Ви можете побачити зразок виводу на веб- сайті http://www.thomas-krenn.com/de/wiki/MySQL_Performance_Tuning#mysqltuner.pl

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

Наступне, що вам слід зробити, це подивитися кеш таблиці. Значення за замовчуванням - 64, що корисно лише в тому випадку, якщо у вас не більше 60 таблиць. Ви хочете підняти це довгий шлях.

Третє, що вам слід зробити - це подивитися на параметри потоку та з'єднання. У більшості веб-застосунків за замовчуванням очікуваний час очікування надзвичайно довгий і може бути скорочений до 30 секунд Це також покращить використання пам’яті, оскільки MySQL швидше почне поновлювати зв’язки, залишаючи набагато менше лежачи у стані «сну».