After a one-time bulk load adds several years of archived loan-tracking records into an existing Fabric Warehouse table, a T-SQL join query that used to return quickly now takes noticeably longer, even though no query text changed. What is the most likely fix?
Select an answer to reveal the explanation.
Short Explanation
The query optimizer plans a join based on its best guess of how much data it's dealing with, and that guess comes from statistics taken at some point in the past. Add years of new rows overnight and that old guess is suddenly way off, so the optimizer picks a plan built for a much smaller table. Refreshing statistics gives it an accurate picture again, and a good plan usually comes right back with it.
Full Explanation
A Warehouse's query optimizer chooses a join strategy — which table to scan first, whether to broadcast or shuffle, how much memory to reserve — based on statistics describing row counts and data distribution, and after a bulk load dramatically changes those counts, stale statistics lead the optimizer to keep planning around outdated assumptions, producing a plan that was reasonable before the load but is poorly suited to the table's new size. Updating (or letting Fabric auto-refresh) statistics gives the optimizer current information to re-evaluate its plan, which is the direct and low-risk fix. Rebuilding a primary key constraint addresses referential integrity, not query planning, and bulk loads don't inherently invalidate keys. Fabric Warehouse tables aren't maintained in a fixed physical row order the way a clustered index in a traditional database might be, so smaller batch sizes wouldn't address a statistics-staleness problem, and there's no described corruption to fix. Dynamic data masking changes what values are displayed to unauthorized users; it doesn't reduce the bytes the optimizer scans or influence plan selection at all. A caveat: for very large or frequently-changing tables, relying solely on automatic statistics updates can lag behind a sudden bulk load, so triggering a manual statistics update right after a known large load is good practice. A concrete check: capture the query's execution plan before and after refreshing statistics and compare the estimated versus actual row counts at each join step.