Databricks SQL: Check Join Row Counts Before Resizing the Warehouse

[amitsharma1707]

When a sales query runs slowly, inspect how many rows each join produces before changing compute size.

Consider a hypothetical retailer joining order lines to payments using order_id. One customer’s order has three product lines and two payment records. Joining these tables directly produces six rows for that order.

If the query then sums line amounts, each product line is counted twice. That extra processing can also make the query slower.

Azure Databricks query profiles show operator-level execution time, row counts, and memory usage, helping identify expensive operations and unexpected row growth.

For this fictional report, I would:

1. Open the query from Query History, then select See query profile.

2. Inspect the join’s input and output row counts.

3. Confirm the report’s intended grain: one row per order.

4. Aggregate order lines and payments separately to that grain before joining.

5. Validate totals and compare execution profiles under comparable conditions.

Multiple matches can be intentional. The important check is whether the join preserves the meaning and grain of the report.

What checks does your team use to distinguish legitimate join expansion from a join that inflates both processing work and business totals?

Reference: Azure Databricks query profile.

#Databricks #SQL #QueryOptimization