Ви запускаєте сайт на 1С-Бітрікс, але сторінки завантажуються по 5–10 секунд. Клієнти йдуть, менеджери скаржаться. Ви перевірили хостинг, кешування, але причина неясна. Slow query log — журнал повільних запитів MySQL — показує справжніх винуватців. Без нього ви гадаєте, а кожна секунда затримки коштує грошей: конверсія падає, бюджет на рекламу згорає. Ми допоможемо проаналізувати журнал, знайти найважчі запити та оптимізувати їх. За 2–3 дні ви отримаєте звіт і готові рішення, а економія від прискорення окупить вкладення за тиждень.
У цій статті розповімо, як увімкнути slow log, які утиліти використовувати для аналізу (mysqldumpslow, pt-query-digest) та які типові запити гальмують Бітрікс. А головне — покажемо на реальному кейсі, як після простого створення індексу час запиту впав з 3 секунд до 10 мілісекунд. Якщо хочете вирішити проблему швидко — зв'яжіться з нами: проведемо аудит за 1 день.
Чому повільні запити — головна проблема Бітрікс?
Основна причина — неоптимальні запити до бази даних. Бітрікс активно використовує інфоблоки, властивості, торгові пропозиції. При великій кількості елементів без правильних індексів кожен запит перетворюється на повне сканування таблиці. Slow query log фіксує такі запити. Ось три типові групи проблем:
- Запити до
b_iblock_elementбез індексу поIBLOCK_IDтаSORT. -
LIKEз провідним відсотком при фільтрації. -
COUNT(*)наb_sale_orderз мільйонами записів. Наш досвід: у 80% випадків достатньо додати 2–3 складових індекси, щоб забрати 90% повільних запитів. Це економить бюджет на дорогий апгрейд серверів.
Як увімкнути та налаштувати slow query log?
У my.cnf (або my.ini на Windows):
[mysqld] slow_query_log = 1 slow_query_log_file = /var/log/mysql/slow.log long_query_time = 0.5 log_queries_not_using_indexes = 1 min_examined_row_limit = 100 long_query_time = 0.5 — запити довше 500 мс. Для активної діагностики ставте 0.1 або навіть 0. log_queries_not_using_indexes = 1 — ловить запити без індексів незалежно від часу. min_examined_row_limit = 100 — не логувати швидкі запити по маленьких таблицях.
Без перезапуску MySQL можна увімкнути динамічно:
SET GLOBAL slow_query_log = 'ON'; SET GLOBAL long_query_time = 0.5; SET GLOBAL log_queries_not_using_indexes = 1; Детальніше про slow log можна прочитати в Wikipedia.
Як знайти повільні запити?
Сирий лог читати незручно. Використовуйте утиліти агрегації: mysqldumpslow — вбудований в MySQL:
mysqldumpslow -s t -t 10 /var/log/mysql/slow.log -s t — сортування за сумарним часом, -t 10 — топ 10 запитів. Показує шаблон запиту та сумарний/середній час.
pt-query-digest (Percona Toolkit) — значно інформативніший: показує процентиль часу виконання, кількість унікальних запитів, навантаження на сервер.
| Утиліта | Швидкість | Інформативність | Дод. можливості |
|---|---|---|---|
| mysqldumpslow | Швидко | Базова | Немає |
| pt-query-digest | Повільніше | Детальна (процентилі, профілі) | Гнучка фільтрація, звіти |
pt-query-digest показує не лише середній час, але й розподіл — у 3 рази детальніше, ніж mysqldumpslow.
Типові повільні запити в Бітрікс
| Проблема | Приклад SQL | Рішення |
|---|---|---|
| Повне сканування каталогу | SELECT * FROM b_iblock_element WHERE IBLOCK_ID=5 ORDER BY SORT |
Складовий індекс (IBLOCK_ID, SORT) |
| LIKE без індексу | SELECT * FROM b_iblock_element_property WHERE VALUE LIKE '%пошук%' |
FULLTEXT індекс або MATCH AGAINST |
| COUNT(*) на замовлення | SELECT COUNT(*) FROM b_sale_order WHERE STATUS='N' |
Індекс по STATUS або партиціонування |
Додавання індексу в першому випадку знижує час виконання з 3 секунд до 0.01 секунди — у 300 разів швидше.
Кейс: як ми прискорили каталог у 20 разів
Клієнт — інтернет-магазин з 50 000 товарів. Сторінки каталогу завантажувалися 6–8 секунд. Slow query log показав запит до b_iblock_element_property з LIKE '%текст%'. Створили FULLTEXT-індекс та переписали запит на MATCH AGAINST. Час виконання впав з 2.3 с до 0.12 с. Загальне завантаження сторінки скоротилося до 1.2 секунд. MySQL FULLTEXT
Хочете так само? Отримайте консультацію — оцінимо ваш випадок за годину.
Що входить у роботу
- Аналіз slow query log за 7 днів (або вказаний період).
- Ідентифікація топ-10 повільних запитів.
- EXPLAIN та рекомендації щодо індексів.
- Реалізація оптимізацій (створення/зміна індексів, рефакторинг запитів).
- Звіт з метриками до/після.
Процес роботи
- Підключення slow log на вашому сервері (віддалено).
- Збір логу за репрезентативний період (зазвичай 1–2 дні).
- Аналіз за допомогою pt-query-digest.
- Видача звіту з пріоритетами.
- Узгодження та реалізація змін.
- Повторний замір для підтвердження.
Терміни: від 1 до 5 днів залежно від складності.
Чому варто довіритися нам?
- 7+ років досвіду з Бітрікс.
- 300+ успішних проєктів.
- Сертифіковані спеціалісти 1С-Бітрікс.
- Працюємо за договором з гарантією результату.
Готові розібратися з гальмуваннями? Зв'яжіться з нами — оцінимо проєкт безкоштовно та запропонуємо рішення за 1 день.