Dans BI Builder, de nouvelles fonctions SQL ont été ajoutées : bitrix24.bi_queries_t()
et bi_explain_query()
. Elles permettent de consulter l'historique des requêtes et d'analyser les causes de lenteur des rapports.
Ces fonctions aident à identifier les filtres appliqués dans les requêtes et le volume de données chargées. Si une requête est trop lente, elle peut être optimisée en ajustant les filtres ou en réduisant le nombre de colonnes sélectionnées.
Dans cet article, nous expliquerons comment :
Consulter l'historique des requêtes SQL
Fonction SQL bitrix24.bi_queries_t()
. Elle permet d'analyser l'historique des requêtes SQL exécutées dans BI Builder. La fonction retourne un tableau contenant des informations telles que les requêtes lancées, le volume de données chargées et d'autres détails sur leur exécution.
Pour consulter l'historique des requêtes :
- Ouvrez BI Builder et accédez à la section SQL > SQL Lab.
- Sélectionnez le schéma
bitrix24
. - Saisissez la requête SQL
SELECT * FROM TABLE(bitrix24.bi_queries_t())
et cliquez sur Exécuter (Run).
Par défaut, la requête affiche les 1 000 dernières requêtes exécutées. Pour limiter le nombre de résultats, utilisez l'opérateur LIMIT
. Par exemple, pour afficher les dix dernières requêtes :
SELECT * FROM TABLE(bitrix24.bi_queries_t()) LIMIT 10;
L'analyse de ce tableau permet d'identifier les requêtes ralentissant les rapports et de les optimiser. Par exemple, si un rapport se charge lentement, examinez les requêtes récentes et notez leur volume et leur durée d'exécution. Si les données sont trop importantes, ajoutez un filtre par date pour réduire l'échantillon et accélérer le chargement.
Ces informations complètent celles disponibles dans la section des statistiques d'utilisation du BI Builder, en fournissant des paramètres supplémentaires pour l'analyse.
Les colonnes du tableau contiennent les détails suivants :
TIMESTAMP - heure d'exécution de la requête. Permet d'identifier les périodes de charge élevée.
QUERY_ID - identifiant unique de la requête. Utilisé avec la fonction bi_explain_query()
pour étudier une requête spécifique.
BI_ENTITY - entité de données concernée. Aide à comprendre quelles données sont associées aux requêtes lentes.
QUERY_RESULT - résultat de la requête (succès ou erreur).
SIZE_BYTES - volume de données chargées. Un volume élevé peut ralentir la requête et nécessiter une optimisation.
ROWS - nombre de lignes retournées. Réduisez ce nombre avec des filtres pour améliorer les performances.
USED_DATE_FILTER - filtre de date appliqué. Vérifiez si la période est correctement limitée.
SELECTED_COLS_CNT - nombre de colonnes sélectionnées. Limitez ce nombre pour accélérer la requête.
SERVER_FILTERS_CNT - nombre de filtres serveur appliqués. L'absence de filtres peut entraîner un chargement excessif de données.
SERVER_FILTERS_INFO - détails des filtres utilisés. Permet de vérifier la pertinence des critères de sélection.
CACHE_SIZE_BYTES - volume de données chargées depuis le cache. Les requêtes utilisant le cache sont plus rapides (durée de vie du cache : 1 heure par défaut).
DOWNLOAD_MILLS - durée du téléchargement des données.
PARSE_MILLS - temps de traitement des données sources par BI Builder avant envoi au serveur. Un volume réduit accélère le traitement.
COMPRESS_MILLS - temps de compression des données avant stockage dans le cache. Plus long pour les volumes importants.
DECOMPRESS_MILLS - temps de décompression des données extraites du cache. Impacte la vitesse d'exécution.
FROM_CACHE - indique si la requête a utilisé le cache (gain de performance).
QUERY_JSON - détails de la requête au format JSON (filtres, paramètres, etc.).
bitrix24.bi_queries_t()
peut être intégrée dans des requêtes SQL : sélection de colonnes spécifiques, application de filtres ou regroupement par champ. Par exemple, pour identifier les 5 requêtes les plus lentes triées par volume de données : Analyser une requête SQL
Fonction SQL bi_explain_query()
. Elle explique l'exécution d'une requête dans la base MySQL de Bitrix24, en révélant les tables, index, jointures et goulots d'étranglement.
Procédure d'analyse :
1. Récupérer QUERY_ID et TIMESTAMP. Exécutez SELECT * FROM TABLE(bitrix24.bi_queries_t())
, repérez la requête concernée et copiez ces valeurs.
2. Exécuter l'analyse. Insérez les valeurs dans la requête : SELECT bi_explain_query('20250328_081146_28230_ixr52', '2025-03-28 08:11:46.964');
Copiez le résultat dans un éditeur de texte pour une analyse détaillée.
Le résultat comprend :
La requête SQL originale. Par exemple, une jointure entre la table des transactions et d'autres tables pour récupérer le nom, la catégorie, le responsable, etc.
Le plan d'exécution. Décrit les étapes suivies par le serveur, avec les colonnes :
- id - numéro de l'étape.
- select_type - type de requête (
SIMPLE
= sans sous-requêtes). - table - table traitée.
- type - méthode de recherche (
ALL
= lente,ref
/eq_ref
= utilisation d'index). - possible_keys - index disponibles.
- key - index utilisé (vide si aucun).
- key_len - taille de l'index (plus courte = meilleure performance).
- ref - champs de jointure.
- rows - nombre de lignes analysées.
- extra - détails (
Using where
= filtre appliqué,Using filesort
= tri coûteux). Documentation MySQL
Version On-Premise : Vous pouvez ajouter des index manuellement.
Version Cloud : Contactez le support pour toute suggestion d'optimisation.
Comment connecter l’assistance de Bitrix24
Résumé
- Les fonctions
bitrix24.bi_queries_t()
etbi_explain_query()
aident à diagnostiquer les lenteurs des rapports. bi_queries_t()
fournit l'historique des requêtes, leur durée et leur volume pour identifier les optimisations possibles.bi_explain_query()
détaille l'exécution des requêtes (tables, index, jointures) pour réduire la charge serveur.