BI Builder ahora incluye dos nuevas funciones SQL: bitrix24.bi_queries_t() y bi_explain_query(). Estas funciones permiten revisar el historial de consultas y analizar por qué tus informes tienen tiempos de carga prolongados.
Con estas funciones podrás descubrir qué filtros se aplican en cada consulta y cuántos datos están siendo procesados. Si detectas consultas lentas, podrás optimizarlas ajustando los filtros o reduciendo el número de columnas.
Contenido del artículo:
Ver el historial de consultas SQL
Función SQL bitrix24.bi_queries_t(). Esta función te permite analizar el historial de consultas SQL ejecutadas en BI Builder. Proporciona un desglose completo que incluye consultas ejecutadas, volumen de datos procesados y otros parámetros operativos clave.
Para ver el historial de consultas:
- Abre BI Builder y ve a la sección de SQL > SQL Lab.
- Selecciona el esquema bitrix24.
- Ingresa la consulta SQL
SELECT * FROM TABLE(bitrix24.bi_queries_t())y haz clic en Run.
Por defecto, la consulta muestra una tabla con 1000 consultas ejecutadas. Para reducir el número de filas, utiliza el operador LIMIT. Por ejemplo, para ver las diez últimas consultas, usa:
SELECT * FROM TABLE(bitrix24.bi_queries_t()) LIMIT 10;
El análisis de esta tabla te permite detectar qué consultas ralentizan los informes y cómo puedes optimizarlas. Cuando notes que un informe tarda en cargar, revisa las consultas más recientes y fíjate especialmente en el volumen de datos que procesan y su tiempo de ejecución. Si el volumen es excesivo, prueba añadiendo filtros por fecha para reducir la cantidad de información y agilizar la carga.
Esta tabla ofrece parámetros de análisis más completos que la sección de estadísticas de consultas en BI Builder. Sus columnas muestran datos detallados sobre cada consulta ejecutada:
| Nombre de la columna | Descripción |
|---|---|
| TIMESTAMP | Fecha y hora exacta de la ejecución de la consulta. Ayuda a detectar momentos con mayor demanda del sistema. |
| QUERY_ID |
Identificador único de la consulta. Puedes usarlo con la función bi_explain_query() para obtener información detallada sobre una consulta en particular.
|
| BI_ENTITY | Conjunto de datos o entidad objetivo. Ayuda a identificar qué bases de información están generando consultas lentas. |
| QUERY_RESULT | Resultado de la consulta. Indica si la consulta se procesó correctamente o si hubo algún problema. |
| SIZE_BYTES | Volumen de datos cargados. Los conjuntos de datos más extensos pueden requerir optimización. |
| ROWS | Cantidad de filas obtenidas. Cuando este número es muy elevado, considera aplicar filtros adicionales para acelerar el rendimiento. |
| USED_DATE_FILTER | Filtro de fecha aplicado. Verifica que esté configurado correctamente para analizar solo el período necesario. |
| SELECTED_COLS_CNT | Cantidad de columnas seleccionadas. Un número elevado puede ralentizar la consulta. Selecciona solo las columnas necesarias. |
| SERVER_FILTERS_CNT | Cantidad de filtros aplicados en el lado del servidor. Cuando faltan filtros, las consultas tienden a ser más lentas porque procesan un volumen mayor de datos |
| SERVER_FILTERS_INFO | Filtros utilizados. Asegura que los datos se seleccionen correctamente. |
| CACHE_SIZE_BYTES | Tamaño de datos cargados desde la caché. Las consultas son más rápidas cuando usan caché, ya que su acceso es más veloz que leer directamente desde Bitrix24. La caché tiene una duración predeterminada de 1 hora. |
| DOWNLOAD_MILLS | Tiempo de descarga de datos. Muestra cuánto tiempo lleva el proceso de carga de datos. |
| PARSE_MILLS | Tiempo que tarda el sistema en procesar los datos antes de enviarlos al servidor. A menor tamaño de datos, menor tiempo de procesamiento. |
| COMPRESS_MILLS | Tiempo requerido para comprimir los datos antes de almacenarlos en caché. La compresión es más lenta con volúmenes mayores de datos. |
| DECOMPRESS_MILLS | Tiempo necesario para descomprimir los datos al recuperarlos de la caché. Datos más grandes requieren más tiempo de descompresión, afectando el rendimiento. |
| FROM_CACHE | Muestra si la consulta utilizó datos almacenados en caché. El acceso a datos en caché mejora significativamente la velocidad de respuesta. |
| QUERY_JSON | Configuración completa de la consulta en formato JSON, incluyendo parámetros y filtros. |
bitrix24.bi_queries_t() se puede usar en consultas SQL para seleccionar columnas específicas, aplicar filtros o agrupar datos por cualquier campo disponible. Por ejemplo, puedes identificar las cinco consultas más lentas y ordenarlas por el volumen de datos procesados.Analizar el rendimiento de consultas SQL
La función SQL bi_explain_query() revela el proceso de ejecución de consultas en la base de datos MySQL de Bitrix24. Muestra tablas e índices utilizados, relaciones entre datos y posibles cuellos de botella que afectan el rendimiento.
Para analizar una consulta en detalle, sigue estos dos pasos:
1. Copia valores QUERY_ID y TIMESTAMP.
- Obtén estos valores de la tabla de historial de consultas (bitrix24.bi_queries_t()).
- Ejecuta la consulta SQL:
SELECT * FROM TABLE(bitrix24.bi_queries_t()). - Encuentra la fila requerida y copia los valores QUERY_ID y TIMESTAMP.
2. Añade parámetros y ejecuta la consulta.
- Inserta los valores copiados en la consulta:
SELECT bi_explain_query('20250328_113555_43337_ixr52', '2025-03-28 11:36:03.525');y ejecútala. - Copia el resultado al portapapeles y revísalo en un editor de texto.
El análisis detalla cómo el servidor procesa la consulta SQL, identificando las tablas e índices utilizados y las operaciones que pueden causar lentitud. La información se presenta en dos secciones:
Consulta SQL original. Revela el proceso de selección de datos desde la tabla de negociaciones y su relación con otras tablas, incluyendo el nombre de la negociación, categoría, responsable, fechas de inicio y cierre, fuente y etapa.
Tabla de análisis de la consulta. Explica paso a paso cómo el servidor ejecuta la consulta. Cada fila corresponde a una operación específica, mientras que las columnas detallan aspectos técnicos del proceso de ejecución.
| Nombre de la columna | Descripción |
|---|---|
| id | Número del paso de ejecución. Indica el orden en que el servidor procesa las tablas durante la consulta. |
| select_type | Tipo de consulta. SIMPLE indica que es una consulta simple sin subconsultas anidadas. |
| table | Nombre de la tabla que el servidor está procesando en ese paso concreto. |
| type |
Método de búsqueda empleado. ALL significa que se escanea toda la tabla (operación lenta), mientras que eq_ref o ref indican uso de índices (operación más eficiente).
|
| possible_keys | Índices que el servidor podría usar en ese paso. |
| key | Índice efectivamente utilizado por el servidor. Si aparece vacío, significa que no se emplean índices, afectando negativamente el rendimiento. |
| key_len | Longitud en bytes de la clave del índice utilizado. Valores menores suelen indicar búsquedas más eficientes. |
| ref | Muestra los campos específicos (IDs de negociaciones, categorías, etapas) que el servidor usa para relacionar tablas, revelando cómo se conectan los datos. |
| rows | Cantidad de filas que el servidor debe examinar en ese paso. Un número elevado suele correlacionarse con mayor tiempo de ejecución. |
| extra |
Detalles adicionales del proceso:
Documentación oficial de MySQL |
Si tienes la versión de Bitrix24 En Premisa, puedes añadir los índices necesarios en la base de datos. En la versión en la nube, no es posible modificar los índices manualmente. Si crees que añadir un índice podría mejorar el rendimiento de las consultas SQL, contacta al soporte técnico.
Soporte de Bitrix24: ¿cómo contactar?
Resumen
- Las nuevas funciones SQL en BI Builder permiten revisar el historial de consultas y analizar por qué tus informes tienen tiempos de carga prolongados.
- La función
bitrix24.bi_queries_t()muestra el historial de consultas SQL, su tiempo de ejecución y el volumen de datos cargados, ayudando a identificar y mejorar las consultas que ralentizan los informes. - La función
bi_explain_query()desglosa detalladamente cómo el servidor ejecuta una consulta específica, mostrando qué tablas e índices se utilizan y qué operaciones la ralentizan, lo que ayuda a acelerar las consultas y reducir la carga en la base de datos.