В BI Конструкторе появились новые SQL-функции: bitrix24.bi_queries_t() и bi_explain_query(). С их помощью можно посмотреть историю запросов и понять, почему отчеты загружаются медленно.

Функции помогут разобраться, какие фильтры используются в запросах и сколько данных они загружают. Если запрос работает медленно, его можно оптимизировать: например, настроить фильтры или уменьшить число колонок.

Посмотреть историю SQL-запросов

SQL-функция bitrix24.bi_queries_t(). Помогает анализировать историю SQL-запросов, выполненных в BI Конструкторе. Функция покажет таблицу с информацией: какие запросы запускались, сколько данных загружалось и другую информацию об их работе.

Чтобы посмотреть историю запросов:

1. Откройте BI конструктор и перейдите в раздел SQL > SQL Lab.
2. Выберите схему bitrix24.
3. Впишите SQL-запрос SELECT * FROM TABLE(bitrix24.bi_queries_t()) и нажмите Выполнить.

По умолчанию запрос выводит таблицу с 1000 выполненных запросов. Чтобы уменьшить количество строк, используйте оператор LIMIT. Например, чтобы посмотреть десять последних запросов, можно использовать запрос:

SELECT * FROM TABLE(bitrix24.bi_queries_t()) 
LIMIT 10;

Анализ таблицы поможет понять, какие запросы замедляют работу отчетов и как их оптимизировать. Например, если отчет долго загружается, посмотрите последние запросы и обратите внимание на их объем и время выполнения. Если данных слишком много, попробуйте добавить фильтр по дате, чтобы уменьшить выборку и ускорить загрузку.

Информация в таблице частично повторяет данные из раздела со статистикой использования запросов в BI Конструкторе, но передает больше параметров для анализа.

В колонках таблицы вы увидите подробную информацию о каждом выполненном запросе:

TIMESTAMP — время выполнения запроса. Показывает, когда именно запрос запускался. Поможет найти периоды с высокой нагрузкой.

QUERY_ID — уникальный номер запроса. Используется вместе с функцией bi_explain_query(). С его помощью можно найти и изучить конкретный запрос.

BI_ENTITY — показывает к каким данным был запрос. Помогает понять, с какими данными связаны медленные запросы.

QUERY_RESULT — результат запроса. Показывает, успешно ли выполнился запрос или была ошибка.

SIZE_BYTES — размер данных, которые загрузил запрос. Если данных много, запрос будет работать медленнее. Можно решить, нужна ли оптимизация.

ROWS — сколько строк вернул запрос. Если строк слишком много, можно добавить фильтр и ускорить работу.

USED_DATE_FILTER — какой фильтр по дате применялся. Позволяет проверить, ограничен ли запрос нужным периодом.

SELECTED_COLS_CNT — сколько колонок было выбрано в запросе. Если колонок много, запрос может замедляться. Можно выбрать только нужные.

SERVER_FILTERS_CNT — количество фильтров, которые применились на сервере. Если фильтров нет, запросы могут работать медленнее. Они будут загружать больше данных.

SERVER_FILTERS_INFO — какие именно фильтры были использованы. Помогает убедиться, что данные отбираются правильно.

CACHE_SIZE_BYTES — размер данных, загруженных из кэша. Запросы из кэша работают быстрее, потому что данные берутся не напрямую из Битрикс24, а из заранее подготовленной копии. По умолчанию кэш действует час.

DOWNLOAD_MILLS — время на скачивание данных. Показывает, сколько времени занимает загрузка данных.

PARSE_MILLS — время, за которое BI Конструктор обрабатывает исходные данные запроса перед отправкой на сервер. Чем меньше исходные данные, тем быстрее обработка.

COMPRESS_MILLS — время, за которое исходные данные сжимаются перед сохранением в кэш. Чем больше объем данных, тем дольше выполняется сжатие.

DECOMPRESS_MILLS — время на распаковку данных после получения их из кэша. Чем больше данных, тем дольше они распаковываются, и это может замедлить работу.

FROM_CACHE — показывает, что запрос выполнился из кэша. Если данные берутся из кэша, запрос выполняется быстрее.

QUERY_JSON — подробная информация о запросе в формате JSON. Можно посмотреть, какие фильтры и параметры использовались при запросе.

Проанализировать SQL-запрос

SQL-функция bi_explain_query(). Показывает, как именно выполняется запрос в базе MySQL Битрикс24. С ее помощью можно узнать, какие таблицы и индексы используются, как соединяются данные и почему запрос может работать медленно.

Чтобы получить подробный анализ запроса, нужно выполнить два шага:

1. Скопировать значения QUERY_ID и TIMESTAMP. Параметры можно взять из таблицы с историей запросов (bitrix24.bi_queries_t()). Выполните SQL-запрос: SELECT * FROM TABLE(bitrix24.bi_queries_t()). Найдите интересующую вас строку и скопируйте значения QUERY_ID и TIMESTAMP.

2. Добавить параметры и выполнить запрос. Добавьте скопированные параметры в запрос: SELECT bi_explain_query('20250319_081208_80250_xqccc', '2025-03-19 08:12:09.418'); и выполните его. Для удобного анализа скопируйте результат в буфер обмена и откройте в любом текстовом редакторе.

Вы получите подробную схему выполнения SQL-запроса. Она показывает, как именно сервер выполняет SQL-запрос: какие таблицы и индексы используются и какие операции замедляют работу. Схема состоит из двух частей:

Исходный SQL-запрос. В примере запрос выбирает данные из таблицы сделок и подключает к ней другие таблицы. Он получает название сделки, ее категорию, ответственного, даты начала и закрытия, источник и стадию.

Таблица с анализом запроса. В ней описаны шаги, по которым сервер выполняет запрос. Каждая строка таблицы — это шаг, который проходит сервер, чтобы получить данные. Таблица состоит из нескольких колонок, каждая из которых объясняет определенную деталь выполнения запроса:

• id — номер шага выполнения. Помогает понять порядок обработки таблиц в запросе.
• select_type — тип запроса. SIMPLE — это значит, что запрос простой и не содержит вложенных подзапросов.
• table — название таблицы, с которой сервер работает на этом шаге.
• type — type — способ поиска данных в таблице. Если указан ALL, сервер просматривает всю таблицу полностью, и запрос выполняется медленно. Если указано eq_ref или ref, сервер использует индекс для поиска, и запрос работает быстрее.
• possible_keys — индексы, которые сервер может использовать на этом шаге.
• key — индекс, который сервер использует при выполнении запроса. Если поле пустое, сервер не использует индексы, и запрос может работать медленнее.
• key_len — длина ключа индекса. Чем короче ключ, тем меньше данных нужно проверить при поиске и тем быстрее может работать запрос.
• ref — показывает поля, по которым соединяются таблицы. Например, по идентификатору сделки, категории или этапу. Это помогает понять, как именно сервер связывает данные между собой.
• rows — количество строк, которые сервер проверит на этом шаге. Чем больше строк, тем медленнее запрос.
• еxtra — дополнительные сведения о выполнении запроса. Using where означает, что сервер применяет фильтр и выбирает только нужные данные. Если в результатах указаны Using filesort или Using temporary, сервер создает временные таблицы или выполняет сортировку на диске. Это может замедлить работу запроса. Список возможных значений можно найти в официальной документации MySQL.
  Официальная документация MySQL

Если у вас коробочная версия Битрикс24, вы можете самостоятельно добавить нужные индексы в базу данных. В облачной версии изменить индексы вручную не получится. Если считаете, что добавление индекса поможет ускорить SQL-запросы, обратитесь в техническую поддержку.
Как написать в поддержку Битрикс24

Рекомендуем прочитать:

• BI Конструктор для создания аналитических отчетов
• BI Конструктор: как обновить данные отчета
• Как работают фильтры по датам в BI Конструкторе