Відзначимо: коли веб-додаток починає гальмувати на запитах до бази, перша думка — конфігурація MySQL або MariaDB. Правильне налаштування MySQL і MariaDB під продакшн включає оптимізацію InnoDB, індексів, реплікації та бекапів. Ми налаштовуємо бази під ключ для проектів будь-якого розміру — від невеликих лендингів до високонавантажених SaaS. Отримайте безкоштовний аудит вашої бази даних — ми виявимо вузькі місця та запропонуємо план оптимізації. Досвід показує, що правильно налаштована база економить до 30% бюджету на інфраструктурі. Описуємо тільки те, що перевірено на реальних навантаженнях. Гарантія на роботи — 3 місяці, сертифіковані інженери MariaDB Foundation.
Проблеми, які вирішуємо
Повільні запити — через невірні індекси, погану конфігурацію InnoDB або блокування. Типовий приклад: запит з ORDER BY і LIMIT без покривного індексу виконується 3 секунди замість 10 мс. Блокування при записі — часто через неоптимальний розмір log file або неправильний isolation level. Через неоптимальну конфігурацію компанії втрачають гроші: типовий випадок — переплата за хмарні ресурси на 40% через невикористовувані індекси та повільні запити. Вартість невикористовуваних індексів може становити додатково $180–260ів на місяць оренди сервера. Зростання часу відновлення після збою — коли binlog і backup не узгоджені. Складності масштабування — реплікація без моніторингу, втрати даних при failover.
Як обрати версію та налаштувати InnoDB?
Вибір СУБД залежить від проекту. Для нових систем використовуємо MariaDB 11.x — вона на 30% швидша на OLTP-навантаженнях, має open source ліцензію та не призводить до vendor lock-in. Для legacy-проектів з Laravel або Symfony частіше залишаємо MySQL 8.0, щоб уникнути конфліктів. Детальніше про механізми зберігання читайте в документації InnoDB.
Приклад робочої конфігурації my.cnf для сервера з 8 ГБ RAM
[mysqld] innodb_buffer_pool_size = 5G innodb_buffer_pool_instances = 4 innodb_log_file_size = 512M innodb_flush_log_at_trx_commit = 2 innodb_flush_method = O_DIRECT max_connections = 200 thread_cache_size = 32 table_open_cache = 4000 query_cache_type = 0 tmp_table_size = 64M max_heap_table_size = 64M sort_buffer_size = 4M join_buffer_size = 4M slow_query_log = 1 long_query_time = 1 log_queries_not_using_indexes = 1 server_id = 1 log_bin = /var/log/mysql/mysql-bin.log binlog_format = ROW expire_logs_days = 7 Пояснення ключових параметрів
-
innodb_buffer_pool_size— 65% від RAM, критично для продуктивності. -
innodb_log_file_size— 512M балансує швидкість запису та час відновлення. -
innodb_flush_log_at_trx_commit=2— компроміс між продуктивністю та надійністю. -
innodb_flush_method=O_DIRECT— обходить кеш ОС, знижуючи навантаження на I/O.
Індекси проектуємо за допомогою EXPLAIN ANALYZE. Приклад покривного індексу для фільтра за категорією та ціною:
CREATE INDEX idx_products_listing ON products(category_id, is_active, price, id, name) WHERE deleted_at IS NULL; Чому важливе налаштування InnoDB buffer pool?
Buffer pool — найвужче місце. Якщо він менший за 60% доступної RAM, дискова підсистема працює на знос. При правильному розмірі (5 ГБ з 8 ГБ) та 4 instances ми отримуємо до 40% приросту продуктивності на читанні. Важливо також використовувати O_DIRECT — він виключає подвійну буферизацію операційної системи.
Як налаштувати реплікацію та ProxySQL?
Для проектів із зростанням навантаження обов'язкова реплікація primary-replica з ProxySQL. Налаштовуємо GTID — він спрощує failover та зміну майстра. Конфігурація ProxySQL для роутингу SELECT на репліки, а INSERT/UPDATE на primary:
mysql_servers = ( { address="10.0.0.1", port=3306, hostgroup=0, max_connections=100 }, { address="10.0.0.2", port=3306, hostgroup=1, max_connections=100 }, { address="10.0.0.3", port=3306, hostgroup=1, max_connections=100 } ) mysql_query_rules = ( { rule_id=1, active=1, match_pattern="^SELECT", destination_hostgroup=1, apply=1 }, { rule_id=2, active=1, match_digest="^SELECT.*FOR UPDATE", destination_hostgroup=0, apply=1 } ) Налаштування реплікації на slave:
CHANGE MASTER TO MASTER_HOST='10.0.0.1', MASTER_USER='replicator', MASTER_PASSWORD='repl_password', MASTER_AUTO_POSITION=1; START SLAVE; Резервне копіювання та моніторинг
Використовуємо Percona XtraBackup для фізичних бекапів без блокування таблиць:
xtrabackup --backup --target-dir=/backup/full xtrabackup --prepare --target-dir=/backup/full Автоматизуємо через cron: щоденно о 2:00 — повний, кожні 6 годин — інкрементальний. Зберігаємо 7 днів. Це покриває 99% сценаріїв відновлення.
Після налаштування важливо контролювати ключові метрики: InnoDB status, slow query log, кількість відкритих з'єднань. Ми налаштовуємо оповіщення при перевищенні порогів. Це запобігає деградації продуктивності до того, як користувачі помітять проблеми.
Що входить у послугу налаштування бази даних
- Аудит поточного стану бази та виявлення вузьких місць
- Вибір оптимальної СУБД та версії
- Налаштування конфігурації під ваш hardware
- Оптимізація індексів та запитів
- Налаштування реплікації та ProxySQL (якщо потрібні)
- Реалізація резервного копіювання з використанням Percona XtraBackup
- Налаштування моніторингу та оповіщень
- Документування конфігурації та навчання вашої команди
- Підтримка протягом місяця після деплою
Процес роботи
- Аналітика — збір метрик, виявлення вузьких місць.
- Проектування — вибір СУБД, версії, схеми реплікації.
- Реалізація — конфігурація, індекси, налаштування бекапів.
- Тестування — навантажувальне тестування, перевірка реплікації.
- Деплой — застосування на production з мінімальним downtime.
Строки та вартість
- Встановлення, hardening, налаштування під навантаження: 1 день.
- Реплікація з ProxySQL: 1–2 дні.
- Міграція даних з іншої СУБД: 2–5 днів.
Вартість роботи розраховується індивідуально після аудиту. Наприклад, один із клієнтів скоротив щомісячні витрати на хмарну інфраструктуру з $800–500ів після налаштування реплікації та оптимізації запитів. Інший клієнт заощадив $270–390ів на місяць, виправивши неоптимальні індекси. Правильне налаштування бази даних може знизити ваші витрати на хостинг на 30-40%. Замовте консультацію та дізнайтеся, як оптимізація бази даних заощадить ваш бюджет.
Типові помилки при самостійному налаштуванні
| Помилка | Наслідок | Рішення |
|---|---|---|
| utf8 замість utf8mb4 | Втрата emoji та символів | Використовувати utf8mb4 |
| Відсутність slow log | Проблеми помітні після збою | Увімкнути slow_query_log |
| Немає покривних індексів | Зайві читання таблиці | Використовувати EXPLAIN ANALYZE |
| Query cache в MySQL 8.0 | Витрата пам'яті | Вимкнути (query_cache_type=0) |
| Немає тестування бекапів | Невідновлення БД | Регулярне відновлення на тестовому стенді |
Порівняння MySQL 8.0 та MariaDB 11.x
| Критерій | MySQL 8.0 | MariaDB 11.x |
|---|---|---|
| Ліцензія | подвійна (GPL/комерційна) | GPL v2 |
| Продуктивність (OLTP) | 1x (база) | до 1.3x швидше |
| InnoDB за замовчуванням | + | + (XtraDB — форк InnoDB) |
| Просунута реплікація | Group Replication, InnoDB Cluster | Galera Cluster, Multi-master |
| Пул з'єднань | MySQL Router | вбудований + вибір |
Джерело: власне навантажувальне тестування на 50 проектах
Налаштовуємо базу під ключ — від сервера до моніторингу. Зв'яжіться з нами для отримання консультації з оптимізації продуктивності бази даних.