The Query Optimizer is like a GPS. It calculates the fastest route to your data. But just as a GPS needs up-to-date maps, the Optimizer needs Statistics to know how many rows are in each table and how the data is distributed.
Statistics are binary objects that store histograms of data distribution in a column. If SQL Server knows that only 1% of users are from 'Iceland', it will use an Index Seek. If it thinks 90% of users are from 'Iceland', it will correctly choose an Index Scan because scanning is faster than 1 million look-ups.
If you insert 1 million rows and don't update statistics, SQL Server might still think the table is empty! It will choose a "Nested Loop" join that works for 10 rows but crashes the server for 1 million. This is called a Bad Cardinality Estimate.
-- Manually update stats for a table
UPDATE STATISTICS Users;Q: "What is 'Parameter Sniffing' and how does it relate to statistics?"
Architect Answer: "Parameter Sniffing happens when SQL Server creates an execution plan based on the *first* parameter passed to a stored procedure. If the first user has 10 records, SQL creates a 'Fast' plan. If the next user has 10 million records, SQL tries to use that same 'Fast' plan, which then becomes incredibly slow. We fix this using `OPTION (RECOMPILE)` or by using local variables to prevent the optimizer from 'sniffing' the specific parameter value."