MySQL Slow Query Log Analysis for 1C-Bitrix: Speed Up Your Site

Is your 1C-Bitrix site slow, and the cause isn't hosting or cache? Slow database queries are a common hidden issue that drives customers away. We analyze the slow query log, find the heaviest queries, and optimize them. Our team delivers the project turnkey—from audit to implementation—ensuring reliable performance and ongoing support.
11+Years of work900+Completed projects100+In house employees19+Partners
Services we offer
Showing 1 of 1All 1626 services
MySQL Slow Query Log Analysis for 1C-Bitrix: Speed Up Your Site
Simple
~2-3 days

Our competencies:

Frequently Asked Questions

You launch a site on 1C-Bitrix, but pages load in 5–10 seconds. Clients leave, managers complain. You checked hosting and caching, but the cause remains unclear. The slow query log — a MySQL log of slow queries — reveals the true culprits. Without it, you're guessing, and every second of delay costs money: conversion drops, ad budget burns. We help analyze the log, find the heaviest queries, and optimize them. In 2–3 days, you'll receive a report and ready-made solutions, and the speed savings will pay for the investment in a week.

In this article, we'll cover how to enable the slow log, which utilities to use for analysis (mysqldumpslow, pt-query-digest), and which typical queries slow down Bitrix. Most importantly, we'll show a real case where a simple index creation dropped query time from 3 seconds to 10 milliseconds. If you want to solve the problem quickly, contact us: we'll conduct an audit in 1 day.

Why slow queries are the main problem for Bitrix

The main cause is non-optimal database queries. Bitrix heavily uses information blocks, properties, and trade offers. With a large number of elements without proper indexes, every query becomes a full table scan. The slow query log catches such queries. Here are three typical problem groups:

  • Queries to b_iblock_element without an index on IBLOCK_ID and SORT.
  • LIKE with a leading wildcard during filtering.
  • COUNT(*) on b_sale_order with millions of records. Our experience: in 80% of cases, adding 2–3 composite indexes eliminates 90% of slow queries. This saves budget for expensive server upgrades.

How to enable and configure the slow query log

In my.cnf (or my.ini on 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 — queries longer than 500 ms. For active diagnostics, set it to 0.1 or even 0. log_queries_not_using_indexes = 1 — catches queries without indexes regardless of time. min_examined_row_limit = 100 — do not log fast queries on small tables.

You can enable it dynamically without restarting MySQL:

SET GLOBAL slow_query_log = 'ON'; SET GLOBAL long_query_time = 0.5; SET GLOBAL log_queries_not_using_indexes = 1;

You can read more about the slow log on Wikipedia.

How to find slow queries

Reading the raw log is inconvenient. Use aggregation utilities: mysqldumpslow — built into MySQL:

mysqldumpslow -s t -t 10 /var/log/mysql/slow.log

-s t — sort by total time, -t 10 — top 10 queries. Shows query pattern and total/average time.

pt-query-digest (Percona Toolkit) — significantly more informative: shows execution time percentiles, number of unique queries, server load.

Utility Speed Informativeness Additional features
mysqldumpslow Fast Basic None
pt-query-digest Slower Detailed (percentiles, profiles) Flexible filtering, reports

pt-query-digest shows not just average time but also distribution — 3 times more detailed than mysqldumpslow.

Typical slow queries in Bitrix

Problem Example SQL Solution
Full catalog scan SELECT * FROM b_iblock_element WHERE IBLOCK_ID=5 ORDER BY SORT Composite index (IBLOCK_ID, SORT)
LIKE without index SELECT * FROM b_iblock_element_property WHERE VALUE LIKE '%search%' FULLTEXT index or MATCH AGAINST
COUNT(*) on orders SELECT COUNT(*) FROM b_sale_order WHERE STATUS='N' Index on STATUS or partitioning

Adding an index in the first case reduces execution time from 3 seconds to 0.01 seconds — 300 times faster.

Case study: how we accelerated a catalog 20 times

A client — an online store with 50,000 products. Catalog pages loaded in 6–8 seconds. The slow query log revealed a query to b_iblock_element_property with LIKE '%text%'. We created a FULLTEXT index and rewrote the query to use MATCH AGAINST. Execution time dropped from 2.3 s to 0.12 s. Overall page load time decreased to 1.2 seconds. MySQL FULLTEXT

Want the same? Get a consultation — we'll evaluate your case in an hour.

What's included in the work

  • Analysis of the slow query log for 7 days (or a specified period).
  • Identification of the top-10 slow queries.
  • EXPLAIN and index recommendations.
  • Implementation of optimizations (creating/altering indexes, query refactoring).
  • Report with before/after metrics.

Work process

  1. Enable slow log on your server (remotely).
  2. Collect log over a representative period (usually 1–2 days).
  3. Analyze using pt-query-digest.
  4. Deliver a report with priorities.
  5. Agree and implement changes.
  6. Re-measure to confirm improvement.

Timeline: 1 to 5 days depending on complexity.

Why trust us?

  • 7+ years of experience with Bitrix.
  • 300+ successful projects.
  • Certified 1C-Bitrix specialists.
  • Work under contract with a guarantee of results.

Ready to fix the slowdown? Contact us — we'll evaluate your project for free and propose a solution within 1 day.

1C Bitrix presentation1C Bitrix24 presentation1C Enterprise presentation