Cuando un informe de BigQuery tarda demasiado, aumentar capacidad puede parecer el camino inmediato. Antes conviene comprobar qué está leyendo y transformando la consulta. Si calcula todos los años para mostrar una semana, el problema puede estar en el alcance del trabajo y no en la potencia disponible.

El diagnóstico debe conservar el resultado de negocio. Una consulta más rápida que excluye devoluciones o interpreta otra fecha no es una optimización válida.

Guarda una referencia antes de modificar SQL

Elige una ejecución representativa y registra sus parámetros, periodo, número de filas y resultado esperado. Guarda el identificador del trabajo para consultar su plan. Anota duración, bytes procesados, consumo de slots y uso de caché cuando la información esté disponible.

No compares una ejecución servida desde caché con otra que procesa los datos y atribuyas toda la diferencia al SQL. Tampoco compares una consulta aislada con otra que compite con muchas cargas sin registrar esa circunstancia.

En el siguiente ejemplo ilustrativo, el equipo necesita ventas diarias por producto durante enero. La tabla contiene años de operaciones, datos logísticos y textos que el informe no muestra.

Primer cambio: hacer explícita la lectura

Si la tabla está particionada por una columna de tipo DATE llamada sale_date, una consulta orientada a esa necesidad podría ser:

SELECT
  sale_date,
  product_id,
  SUM(net_amount) AS net_sales
FROM analytics.sales
WHERE sale_date >= DATE '2026-01-01'
  AND sale_date < DATE '2026-02-01'
GROUP BY sale_date, product_id;

El ejemplo presupone que net_amount ya aplica la definición acordada de venta neta. Si el cálculo requiere devoluciones registradas después del cierre, el periodo y la regla deben adaptarse; el filtro no puede decidir la política contable del informe.

Seleccionar columnas concretas evita arrastrar campos ajenos al resultado. Un filtro utilizable sobre la partición permite limitar las particiones examinadas. Hay que comprobar que la tabla realmente utiliza esa columna para particionar y que el plan aplica la reducción esperada.

Google advierte que añadir LIMIT a un SELECT de todas las columnas no reduce necesariamente la lectura. Devolver pocas filas y procesar pocos datos son cuestiones distintas. Para inspeccionar contenido, utiliza las opciones de vista previa que correspondan.

Segundo cambio: comprobar si una unión multiplica filas

Imagina que cada producto tiene varios registros de clasificación histórica. Si unes ventas con esa tabla solo por product_id, una venta puede encontrar varias coincidencias. La consulta genera más filas y el importe agregado puede aumentar indebidamente.

Antes de intentar acelerar esa unión, determina cuál es la relación correcta: clasificación vigente en la fecha de venta, clasificación actual o reparto intencionado entre categorías. Cada interpretación produce un modelo distinto.

Una prueba útil consiste en contar las filas por identificador de venta antes y después de la unión. Investiga las ventas con más coincidencias de las previstas. También compara importes en una muestra pequeña donde puedas explicar cada resultado.

El plan de ejecución ayuda a localizar etapas que producen muchas más filas de las que reciben. Esa señal merece revisar cardinalidad y filtros; no demuestra por sí sola que la unión sea errónea.

Tercer cambio: separar costes y tiempos

La reducción de datos procesados tiene consecuencias diferentes según el modelo de facturación. En consultas bajo demanda resulta relevante para el coste de análisis, sujeto a las reglas del servicio. En capacidad reservada, reducir trabajo puede mejorar la utilización sin reducir automáticamente la factura comprometida.

Los controles de BigQuery incluyen estimaciones mediante ejecuciones en seco y límites de bytes facturados para los casos compatibles. La guía oficial de control de costes explica su aplicación y límites. Son controles que conviene ajustar al tipo de consulta y facturación, sin tratarlos como un presupuesto universal para todos los recursos.

Mantén separados tres resultados: corrección del dato, comportamiento de ejecución y efecto económico. Para relacionar este último con un producto o equipo, define también la atribución de costes cloud por carga de trabajo. Una mejora en uno no acredita automáticamente los otros dos.

Una hoja de diagnóstico que permite decidir

Observación Comprobación siguiente Evidencia para aceptar el cambio
Se leen periodos que no utiliza el informe Revisar particionado y filtros Menos lectura con el mismo periodo de negocio
Una unión genera muchas filas Revisar claves y cardinalidad Cada venta tiene las coincidencias previstas
La consulta espera aunque lee poco Revisar competencia y capacidad Comparación de ejecuciones en condiciones equivalentes
El mismo cálculo se repite en muchos informes Evaluar materialización y actualización Frescura suficiente y coste total de mantenimiento conocido

Repite la comparación con los mismos parámetros y un volumen representativo. Incluye periodos sin datos, cierres con devoluciones y productos que cambian de clasificación. Conserva la consulta anterior hasta comprobar que el resultado sigue siendo válido.

La capacidad adicional tiene sentido cuando el trabajo necesario está bien definido y la limitación medida lo justifica. En una revisión de plataformas de datos y Big Data, Nexeus Big Data puede ayudarte a plantear el diagnóstico a partir de consultas, planes de ejecución y requisitos del informe, sin presuponer un ahorro antes de medirlo.