Дата публикации: 24.06.2026

Выполняем оптимизацию и анализ таблиц базы прямо из монитора производительности

Что вы сразу получите

Понимание, какие метрики в мониторе производительности указывают на проблемы с таблицами MySQL/MariaDB.
Пошаговый план оптимизации индексов и перестройки таблиц без остановки сайта.
Практический набор команд, которые можно выполнить из консоли или из встроенного SQL‑монитора в Битриксе.

1. Почему таблицы «запыхивают»?

Признак	Что происходит	Как это выглядит в мониторе
Высокий `Rows_examined`	Система сканирует почти все строки, а не только нужные.	`Rows_examined_per_second` → > 10 000
Низкий `Rows_sent`	Запрос возвращает мало данных, но тратит много времени.	`Rows_sent_per_second` → < 100
Большой `Handler_read_rnd_next`	Случайный доступ к строкам без индекса.	`Handler_read_rnd_next_per_second` → > 5 000
`Slow_queries` растёт	Запросы превышают `long_query_time`.	`Slow_queries` → > 50 за минуту

Эти цифры – сигналы, что таблица нуждается в реинженерии: добавить/перестроить индексы, разбить на партиции, очистить «мусорные» данные.

2. Как быстро увидеть проблемные таблицы

2.1. Встроенный «SQL‑монитор» в админке Битрикса

Откройте Контроль → Мониторинг → MySQL.
Сортируйте по колонке Rows_examined – вверху будут «тяжёлые» запросы.
Нажмите на кнопку «Показать план выполнения», чтобы увидеть EXPLAIN.

2.2. Команда `SHOW GLOBAL STATUS`

SHOW GLOBAL STATUS LIKE 'Handler%';
SHOW GLOBAL STATUS LIKE 'Rows%';
SHOW GLOBAL STATUS LIKE 'Slow_queries';

Эти строки дают глобальную картину. Чтобы сузить область, используйте information_schema:

SELECT 
    TABLE_SCHEMA,
    TABLE_NAME,
    ENGINE,
    TABLE_ROWS,
    DATA_LENGTH/1024/1024 AS data_mb,
    INDEX_LENGTH/1024/1024 AS index_mb,
    (DATA_LENGTH+INDEX_LENGTH)/1024/1024 AS total_mb
FROM information_schema.TABLES
WHERE ENGINE='InnoDB'
ORDER BY total_mb DESC
LIMIT 10;

Топ‑10 самых «тяжёлых» таблиц сразу попадают в ваш список приоритетов.

3. Диагностика индексов

3.1. План выполнения (`EXPLAIN`)

Поле	Что показывает	Как интерпретировать
`type`	Тип доступа к таблице	`ALL` → полный скан, плохой; `ref`, `eq_ref` → индекс работает
`key`	Какой индекс использован	`NULL` → не используется
`rows`	Оценка количества строк, которые будут прочитаны	Большие числа → нужен лучший индекс
`Extra`	Дополнительные детали	`Using filesort` / `Using temporary` → можно улучшить

3.2. Проверка «мёртвых» индексов

SELECT 
    TABLE_SCHEMA,
    TABLE_NAME,
    INDEX_NAME,
    CARDINALITY,
    SUB_PART,
    INDEX_TYPE
FROM information_schema.STATISTICS
WHERE TABLE_SCHEMA = 'your_db'
AND INDEX_NAME NOT IN (
    SELECT DISTINCT INDEX_NAME
    FROM information_schema.KEY_COLUMN_USAGE
    WHERE TABLE_SCHEMA = 'your_db'
);

Индексы, которые не попадают в KEY_COLUMN_USAGE, не участвуют в запросах и только занимают место.

4. Практические шаги оптимизации

4.1. Добавление недостающих индексов

Определите столбцы из WHERE, JOIN, ORDER BY.

Сформируйте индекс:

ALTER TABLE `b_catalog_product`
ADD INDEX `idx_price_category` (`price`, `category_id`);

Проверьте, как изменился план: EXPLAIN SELECT ….

4.2. Перестройка существующих индексов

Если индекс фрагментирован (показатель STATISTICS → INDEX_LENGTH сильно превышает DATA_LENGTH), выполните:

ALTER TABLE `b_catalog_product` ENGINE=InnoDB;

Эта команда перестраивает таблицу, создавая новые индексы и освобождая место. Делайте её в «тихие» часы, а в режиме ALGORITHM=INPLACE, LOCK=NONE (MySQL 5.6+), чтобы не блокировать запросы.

4.3. Разбиение (партиционирование)

Для таблиц с миллионами строк (например, b_sale_order) рекомендуется партиционирование по дате:

ALTER TABLE `b_sale_order`
PARTITION BY RANGE (YEAR(`date_insert`)) (
    PARTITION p2020 VALUES LESS THAN (2021),
    PARTITION p2021 VALUES LESS THAN (2022),
    PARTITION p2022 VALUES LESS THAN (2023),
    PARTITION p_future VALUES LESS THAN MAXVALUE
);

Это ускорит запросы, ограниченные диапазоном дат, и упростит очистку старых данных.

4.4. Очистка «мусорных» записей

DELETE FROM `b_log` 
WHERE `timestamp` < DATE_SUB(NOW(), INTERVAL 90 DAY);
OPTIMIZE TABLE `b_log`;

OPTIMIZE TABLE уплотняет файлы .ibd и уменьшает Data_length.

5. Мониторинг после изменений

Метрика	Ожидаемый результат
`Rows_examined_per_second`	Снижение в 2–5 раз
`Handler_read_rnd_next_per_second`	Падение до < 500
`Slow_queries`	Уменьшение на 70 % и более
`Disk I/O` (в монитороре сервера)	Снижение записи/чтения на 30 %

Создайте алерт в системе мониторинга (например, Zabbix) на Slow_queries > 20 и Rows_examined_per_second > 5000. Это позволит быстро реагировать, если что‑то пошло не так.

6. Как автоматизировать проверку

#!/bin/bash
DB="bitrix"
HOST="localhost"
USER="monitor"
PASS="********"

mysql -h $HOST -u $USER -p$PASS -e "
SELECT 
    TABLE_SCHEMA,
    TABLE_NAME,
    ROUND((DATA_LENGTH+INDEX_LENGTH)/1024/1024,2) AS total_mb,
    ROUND(DATA_LENGTH/1024/1024,2) AS data_mb,
    ROUND(INDEX_LENGTH/1024/1024,2) AS index_mb
FROM information_schema.TABLES
WHERE ENGINE='InnoDB' AND TABLE_SCHEMA='$DB'
ORDER BY total_mb DESC
LIMIT 5;
" | mail -s "Top 5 biggest tables on $(date)" admin@example.com

Скрипт отправит вам список самых «тяжёлых» таблиц каждый день. Подключите его к cron (0 2 * * * /path/to/script.sh).

7. Частые ошибки и как их избежать

Ошибка	Почему происходит	Как исправить
Создание индекса без анализа	Индекс может быть слишком широким, занимать много места и не ускорять запрос.	Сначала выполните `EXPLAIN`, посмотрите `rows`.
Перестройка таблицы в часы пик	Блокировка может привести к падению сайта.	Используйте `ALGORITHM=INPLACE, LOCK=NONE` и планируйте на low‑traffic.
Партиционирование без учёта запросов	Если запросы не используют колонку партиционирования, выгода нулевая.	Выбирайте колонку, часто встречающуюся в `WHERE`/`ORDER BY`.
Игнорирование `innodb_buffer_pool_size`	Неподходящий размер кэша приводит к постоянным чтениям с диска.	Установите `innodb_buffer_pool_size` ≈ 70 % ОЗУ сервера.

Практика для закрепления

Определите «тяжёлую» таблицу на вашем сайте, используя запрос к information_schema.TABLES. Какие столбцы занимают больше 80 % места?
Сформируйте план выполнения для запроса, который часто появляется в slow_query_log. Какие индексы задействованы? Что говорит поле type?
Создайте недостающий индекс для выбранного запроса, затем сравните Rows_examined до и после изменения.
Разбейте таблицу b_sale_order на партиции по году, если в ней более 5 млн записей. Как изменится время выполнения запроса SELECT * FROM b_sale_order WHERE date_insert BETWEEN '2022-01-01' AND '2022-12-31'?
Автоматизируйте отчёт о самых больших таблицах и настройте email‑оповещение. Приведите пример скрипта (можно на Bash или Python) и объясните, как часто его следует запускать.

Полезные ссылки

Документация MySQL – EXPLAIN
VDSina – провайдер, где можно арендовать мощный VDS для тестов.

С помощью этих техник вы сможете быстро находить узкие места в базе, устранять их без простоя сайта и поддерживать стабильную работу даже при росте трафика. Удачной оптимизации!

CamZamZam - онлайн фото с вебкамеры с эффектами
Cartoon Network: игры с персонажами
Чат рулетка в 2026: будущие функции
Эксперт по доменным стратегическим решениям
Хостинг для e-commerce проектов
Как играть в слоты
Как настроить CDN для сайта на хостинге Host.bg
Как настроить SSL-сертификат для сайта на Host.bg
Как оптимизировать производительность сайта с хостингом Host.bg
Как выбрать правильный хостинг для вашего сайта
Какие бывают ЛОР болезни у детей
Кассовые терминалы с оплатой картами
LOL куклы витрина детская
Лучшие видеорегистраторы для водителей
Онлайн QR-код сканер
Онлайн-связь
Оптимизация производительности баз данных на хостинге Host.bg
Основы настройки веб-хостинга: что вам нужно знать
Партнёрская программа без блога: как получать трафик из Telegram
Профессиональные хитрости для пользователей хостинга Host.bg
Регистрация ИП в Москве для иностранных граждан
Сравнение хостинга Host.bg с другими провайдерами
Субтитры — нет, уши — включены: погружение в английский за 5 минут
Сумки с бусинами
Техника для строительства загородных трасс
ТОП-10 VPS для разработчика: рейтинг серверов под рабочие задачи
WordPress блог для бизнеса