The short answer
In Azure Synapse, all 60 distributions execute query steps in parallel. The overall query latency is dictated by the slowest distribution. Distribution skew occurs when an improper HASH key allocates significantly more rows to certain distributions than others.
Diagnosing data skew
Query the dynamic management view sys.dm_pdw_nodes_db_partition_stats to inspect row counts across each of the 60 distributions:
SELECT
distribution_id,
SUM(row_count) as total_rows
FROM sys.dm_pdw_nodes_db_partition_stats
WHERE object_id = OBJECT_ID('dbo.fact_sales')
GROUP BY distribution_id
ORDER BY total_rows DESC;If one distribution holds 15 million rows while another holds 50,000 rows, the table is heavily skewed. When queries execute, the single core processing the 15-million-row slice runs out of memory, while other nodes sit idle.
The Data Movement Service (DMS)
When a query joins 2 tables that are not colocated on the join key, the Data Movement Service must transfer data between compute nodes during execution:
- BroadcastMoveOperation: Copies an entire table across the network to every compute node. This is normal and fast for small under two gigabytes.
- ShuffleMoveOperation: Re-hashes and sends rows from large tables across the network to match the target join key.
- PartitionMoveOperation: Moves table across distributions without network transformations.
In an , finding a ShuffleMoveOperation on a multi-billion-row indicates that your tables are distributed on mismatched keys, resulting in massive network transfer delays.