How SQL Server Optimizes a Query: From T-SQL Text to Execution Plan

How SQL Server Optimizes a Query: From T-SQL Text to Execution Plan

SQL Server is not simply executing the SQL you typed. It is understanding it, validating it, simplifying it, transforming it and considering alternative ways of achieving the same result.

That sentence changes how you approach query performance.

When a query is slow, the first instinct is often to rewrite the text, add an index or blame SQL Server. Those actions may occasionally help, but they skip the most important question:

What did SQL Server understand, what alternatives did it consider, and why did it choose this execution plan?

This guide develops that mental model from the first three chapters of *SQL Server Query Tuning and Optimization*. It is not a catalogue of tuning tricks. It is a mentoring journey through the query processor, execution plans, evidence-led troubleshooting and the cost-based optimizer.

The goal is to help you stop treating a SQL statement as a list of instructions and start seeing it as a request for a result.

---

The central idea: SQL is declarative

Consider this query:

SELECT
    o.OrderId,
    o.OrderDate,
    c.CustomerName
FROM Sales.Orders AS o
INNER JOIN Sales.Customers AS c
    ON c.CustomerId = o.CustomerId
WHERE o.OrderDate >= '2026-01-01';

You have described the result you want:

• orders from a particular date onwards;
• matching customer names;
• three columns in the result.

You have not normally dictated:

• which table must be accessed first;
• whether SQL Server should scan or seek;
• which join algorithm it should use;
• whether it should run serially or in parallel;
• how much memory it should request;
• whether an existing compiled plan can be reused.

SQL Server must decide how to produce the requested rows.

This separation is the foundation of relational query processing:

Your responsibility
Describe the correct result

SQL Server's responsibility
Find a legal and reasonably efficient way to produce it

The word reasonably matters. For a complex query, the number of possible execution plans can become enormous. The optimizer cannot spend unlimited time proving which plan is mathematically perfect. It searches intelligently, estimates costs and aims to find a good plan within a sensible compilation budget.

---

1. The two broad sides of SQL Server query processing

At a high level, two parts of the database engine cooperate.

The relational engine

The relational engine, often called the query processor, is responsible for understanding the query, producing an execution plan and coordinating its execution.

Its work includes:

• parsing the T-SQL;
• resolving names and types;
• building an internal logical representation;
• simplifying that representation;
• exploring possible physical strategies;
• estimating their costs;
• selecting a plan.

The storage engine

The storage engine deals with access to the underlying data structures. It reads pages, uses indexes, manages locking and latching concerns, and returns rows to the operators requesting them.

The relationship is easier to understand as a conversation:

Relational engine
"This is the physical plan I selected."
        ↓
Storage engine
"I will access the required pages and rows."
        ↓
Execution operators
"We will process and return the result."

You do not tune one side in isolation. A plan is a set of physical operations, and those operations ultimately drive real work against memory, CPU, storage and data structures.

---

2. Parsing: can SQL Server understand the language?

The first challenge is syntactic.

If you submit invalid T-SQL, SQL Server cannot proceed:

SELEC CustomerId
FROM Sales.Customers;

The parser checks whether the submitted text follows the grammar of T-SQL. It identifies keywords, expressions, clauses and their relationships, then produces an internal representation of the statement.

Passing the parser does not prove that the query is valid against your database. It only means the language structure can be understood.

This distinction becomes important in the next stage.

---

3. Binding: do the referenced objects and expressions make sense?

Binding connects the parsed query to database metadata.

SQL Server must resolve questions such as:

• Does Sales.Orders exist?
• Does the current identity have permission to access it?
• Which table does CustomerId refer to?
• Does OrderDate exist?
• Are the compared data types compatible?
• What type and nullability should each expression produce?

For example:

SELECT CustomerId
FROM Sales.Orders AS o
INNER JOIN Sales.Customers AS c
    ON c.CustomerId = o.CustomerId;

This query may be ambiguous because both tables can expose a column called CustomerId. Qualifying the column removes the ambiguity:

SELECT o.CustomerId
FROM Sales.Orders AS o
INNER JOIN Sales.Customers AS c
    ON c.CustomerId = o.CustomerId;

Binding is more than checking spelling. It gives meaning to the parsed tree by associating names with real objects, columns, data types and metadata.

A query cannot be meaningfully optimized until SQL Server understands what every part refers to.

---

4. From query text to a logical tree

Once parsed and bound, the query is represented internally as logical relational operations.

Developers see:

SELECT ProductId, Name
FROM Production.Product
WHERE ProductId = 877;

The optimizer reasons in concepts closer to:

Project ProductId, Name
        ↓
Filter ProductId = 877
        ↓
Get Production.Product

This is an important change of perspective.

The optimizer is not rearranging the visible SQL text like a word processor. It is working with a tree of logical operations that describe the required result.

Logical operations describe what must happen:

• retrieve rows;
• filter rows;
• join sets;
• group values;
• project required columns.

Physical operators describe how the work can happen:

• index seek;
• table or index scan;
• nested loops;
• merge join;
• hash match;
• sort;
• stream aggregate.

One logical operation may have several possible physical implementations. A logical join, for example, is not automatically a nested loops join. The optimizer chooses among legal alternatives using its estimates and costing model.

---

5. Simplification: remove work before exploring plans

Before searching a large plan space, SQL Server tries to simplify the logical tree.

This is one of the most valuable ideas in the optimizer: the cheapest operation is often the one that can be proved unnecessary.

Contradiction detection

Consider:

SELECT ProductId
FROM Production.Product
WHERE ProductId = 100
  AND ProductId = 200;

One value cannot equal both constants. If SQL Server can prove the contradiction, it may produce a constant-scan style result that returns no rows without accessing the table in the ordinary way.

The optimizer has not made the query text prettier. It has proved that the requested result is empty and removed unnecessary work.

Constant folding

Expressions that can be safely calculated during optimization may be reduced:

WHERE Quantity > 10 * 5

can be reasoned about as:

WHERE Quantity > 50

The exact transformations depend on expression rules, types and safety, but the principle is that known work can sometimes be performed once rather than repeatedly during execution.

Join elimination

Trusted constraints can prove that a join contributes nothing to the requested result.

Suppose every order has a valid customer because a trusted foreign key enforces that relationship:

SELECT o.OrderId
FROM Sales.Orders AS o
INNER JOIN Sales.Customers AS c
    ON c.CustomerId = o.CustomerId;

If no customer columns are required and the metadata proves every order has a matching customer, SQL Server may be able to remove the join.

This reveals a deeper performance lesson:

Constraints are not only integrity rules. Trusted metadata can give the optimizer facts that support safer simplification and better reasoning.

Do not remove foreign keys in the name of performance without understanding what information and protection you are taking away.

Subqueries and equivalent relational forms

Some subqueries can be transformed into joins or other relational forms. Redundant joins, filters or expressions may be removed or reorganised when relational equivalence permits it.

The visible syntax is therefore not a reliable description of the final work. Two differently written queries can become similar internal trees, while two visually similar queries can produce different plans because their types, predicates, statistics or metadata differ.

---

6. Trivial plans: not every query needs a large search

Some queries have an obvious low-cost strategy and do not justify extensive optimization.

For example:

SELECT ProductId, Name
FROM Production.Product
WHERE ProductId = 877;

If an appropriate unique access path exists and there is little meaningful choice, SQL Server may use trivial plan optimization.

This is not SQL Server being careless. Optimization itself consumes CPU and time. Spending 100 milliseconds exploring alternatives to save one millisecond of execution time would be a poor trade.

Compilation and execution are both costs.

The optimizer must balance:

Time spent searching for a better plan
                versus
Time likely to be saved when the plan executes

This balance becomes more important for complex queries and frequently compiled workloads.

---

7. Equivalent results can have many physical plans

Imagine joining three tables:

Customers
Orders
OrderLines

SQL Server may consider different join orders:

(Customers join Orders) join OrderLines

Customers join (Orders join OrderLines)

(OrderLines join Orders) join Customers

For each join, there may also be physical alternatives:

Nested Loops
Merge Join
Hash Match

Access choices multiply the possibilities further:

Index seek
Index scan
Table scan
Lookup

For a larger query, exhaustively testing every legal combination would take too long. The optimizer therefore applies transformation rules and heuristics to explore promising regions of the search space.

It aims for a good enough plan within the available optimization time, not a proof that no better plan exists anywhere.

---

8. Transformation rules: different trees, same meaning

Relational algebra allows expressions to be transformed while preserving their result.

One simple example is join commutativity:

A join B

can be logically equivalent to:

B join A

Join associativity permits other reorderings when the semantics allow them.

The optimizer uses several broad categories of rule:

• Simplification rules reduce the logical tree.
• Exploration rules generate logically equivalent alternatives.
• Implementation rules map logical operations to physical operators.

The power comes from combining them.

Original logical expression
        ↓ simplify
Smaller logical expression
        ↓ explore
Equivalent logical alternatives
        ↓ implement
Physical plan alternatives
        ↓ cost
Selected execution plan

This is why forcing one join order or physical operator can be risky. A hint can prevent the optimizer from exploring alternatives that would have been better for a different parameter value, data distribution or database state.

Hints sometimes have a legitimate role, but they should be a measured intervention after the underlying estimates, statistics, indexes and query design have been investigated.

---

9. The Memo: remembering alternatives without rebuilding everything

As alternatives are generated, the optimizer needs a way to organise them.

The internal Memo structure groups expressions that are logically equivalent. Alternatives in the same group produce the same result even if their physical strategies differ.

Conceptually:

Memo group: "Orders joined to Customers"

Logical alternatives
- Orders join Customers
- Customers join Orders

Physical alternatives
- Nested Loops
- Merge Join
- Hash Match

The actual internal structure is far more sophisticated, but this simplified view explains why optimization is not a flat list of complete plans. SQL Server can compare and reuse groups of alternatives as it searches.

The number of alternatives can still grow rapidly, which is another reason optimization needs phases, pruning and time limits.

---

10. Cost-based optimization: compare estimated work

SQL Server assigns an estimated cost to candidate plans.

The cost is not elapsed time in seconds and should not be read as a promise. It is an internal comparative value based on a model of expected work, including CPU and I/O considerations.

The optimizer asks questions such as:

• How many rows are likely to reach this operator?
• How many pages may need to be read?
• Is ordered input already available?
• How expensive would sorting be?
• Would repeated seeks be cheaper than scanning once?
• How much memory might a hash or sort require?
• Is a parallel alternative worth its coordination cost?

It then compares alternatives under the same model.

The quality of the chosen plan depends heavily on the quality of the estimates.

---

11. Statistics: the optimizer's map of the data

The optimizer does not normally inspect every row during compilation. It uses statistics and metadata to estimate cardinality: how many rows are likely to flow through each stage.

Suppose a table contains ten million orders, but only fifty have Status = 'FraudReview'.

SELECT OrderId, CustomerId
FROM Sales.Orders
WHERE Status = 'FraudReview';

If SQL Server estimates fifty rows, a selective access path and nested loops may be sensible.

If it incorrectly estimates several million rows, it may favour a scan or a different join strategy.

The plan can be logically valid while being operationally poor because its estimates were poor.

This leads to one of the strongest execution-plan habits:

Compare estimated rows with actual rows. Large differences are often more revealing than whether an icon says seek or scan.

Estimate quality can be affected by:

• stale or unrepresentative statistics;
• skewed data;
• correlations between columns;
• expressions that hide useful distribution information;
• implicit conversions;
• parameter values;
• temporary objects or table variables in particular contexts;
• assumptions made by the cardinality estimator.

Do not immediately update every statistic or rebuild every index. First find where the estimates diverge and understand why.

---

12. Optimization phases: stop when a suitable plan is found

SQL Server can use different optimization depths depending on query complexity and the plans found.

A simplified mental model is:

Search 0

An early search suited to relatively small transactional queries. It uses limited exploration and aims to find an acceptable plan quickly.

Search 1

A broader search with additional transformations and join-order exploration. Serial and, where relevant, parallel alternatives may be assessed.

Search 2

A more extensive search used when earlier phases have not found a plan below their internal thresholds.

The exact internal behaviour is implementation detail and can evolve, but the enduring lesson is clear:

Optimization is budgeted. SQL Server expands its search when the expected benefit justifies more compilation work and stops when it has a sufficiently good candidate or reaches its limits.

This explains why optimization timeout does not automatically mean a query failed. It means the optimizer stopped exploring and selected the best alternative it had found within its search budget.

---

13. The execution plan is the optimizer's chosen strategy

The selected plan is a tree of physical operators.

In SQL Server Management Studio, you commonly work with:

• Estimated execution plan: compiled without executing the statement;
• Actual execution plan: execution plus runtime information collected for the plan;
• Live query statistics: progress information while a query is executing, used selectively because observation has overhead;
• XML Showplan: the detailed machine-readable representation behind the graphical display.

The graphical plan is a useful starting point, but do not read it as a row of icons alone.

Inspect operator properties such as:

• estimated and actual rows;
• number of executions;
• predicates and seek predicates;
• output columns;
• object and index names;
• estimated row size;
• memory grant information;
• ordering requirements;
• parallelism details;
• warnings;
• actual elapsed and CPU information where available.

The arrows matter too. Their thickness gives a visual indication of row flow. A plan that returns ten rows at the end may move millions of rows between earlier operators.

The expensive-looking operator is not always the root cause. A sort or hash may be costly because an earlier estimate was wrong or because a filter was applied too late.

Read the plan as a flow of data, not a collection of isolated symbols.

---

14. Plan warnings are leads, not automatic diagnoses

Execution plans can surface warnings such as:

• implicit conversions;
• missing statistics;
• excessive or insufficient memory grant behaviour;
• spills to tempdb;
• missing-index suggestions;
• unmatched indexes;
• columns with no statistics;
• join or cardinality concerns.

A warning tells you where to investigate. It does not automatically tell you what change to make.

A missing-index suggestion, for example, is generated from the perspective of a particular query and cost estimate. It does not know your entire indexing strategy, write workload, storage budget or overlapping indexes.

Treat warnings as evidence:

Warning
   ↓
Understand the underlying condition
   ↓
Measure workload impact
   ↓
Choose the smallest safe intervention
   ↓
Validate before and after

---

15. Measure reads and CPU with STATISTICS IO and TIME

Execution plans explain strategy. Runtime measurements help quantify the work.

SET STATISTICS IO ON;
SET STATISTICS TIME ON;

SELECT
    o.OrderId,
    o.OrderDate
FROM Sales.Orders AS o
WHERE o.CustomerId = 12345;

SET STATISTICS TIME OFF;
SET STATISTICS IO OFF;

SET STATISTICS IO reports information including logical reads. A logical read represents a page accessed from SQL Server's buffer cache.

If two queries return the same result and one performs 100 logical reads while another performs 100,000, the difference deserves attention even if a quick development test makes both appear fast.

SET STATISTICS TIME reports CPU and elapsed timing information.

Interpret the two together:

High elapsed time, low CPU
Possibly waiting, blocking, I/O or another resource delay

High CPU time
The query is consuming substantial processor work

High logical reads
The query is touching many data pages

One isolated execution is not a production benchmark. Cache state, concurrency, parameter values and system load all matter. The purpose is to replace guesses with comparable evidence.

---

16. Troubleshooting begins with the right question

"The database is slow" is not yet a diagnosis.

Ask:

• Is one query slow or is the whole server affected?
• Is the query currently running or historically expensive?
• Is it slow every time or only for certain parameters?
• Is it consuming CPU or waiting?
• Is it blocked by another session?
• Did performance change after deployment or data growth?
• Is the compiled plan different from the previously good plan?
• Are estimates far from actual row counts?

Different questions require different evidence sources.

---

17. See active work with requests and sessions

sys.dm_exec_requests shows currently executing requests. sys.dm_exec_sessions describes connected sessions.

A simplified diagnostic query might begin like this:

SELECT
    r.session_id,
    r.status,
    r.command,
    r.cpu_time,
    r.total_elapsed_time,
    r.logical_reads,
    r.reads,
    r.writes,
    r.wait_type,
    r.wait_time,
    r.blocking_session_id
FROM sys.dm_exec_requests AS r
WHERE r.session_id <> @@SPID;

This helps you distinguish a request that is running from one that is suspended and waiting.

DMV information is transient and permissions are required. Capture it while the problem is occurring or use an appropriate monitoring platform to retain history.

---

18. Find expensive cached statements with query statistics

sys.dm_exec_query_stats exposes aggregate information for cached query plans. It can help identify statements with high cumulative CPU, reads or elapsed time.

SELECT TOP (20)
    qs.execution_count,
    qs.total_worker_time,
    qs.total_worker_time / NULLIF(qs.execution_count, 0)
        AS average_worker_time,
    qs.total_logical_reads,
    qs.total_logical_reads / NULLIF(qs.execution_count, 0)
        AS average_logical_reads,
    qs.total_elapsed_time,
    SUBSTRING(
        st.text,
        (qs.statement_start_offset / 2) + 1,
        ((CASE qs.statement_end_offset
            WHEN -1 THEN DATALENGTH(st.text)
            ELSE qs.statement_end_offset
          END - qs.statement_start_offset) / 2) + 1
    ) AS statement_text
FROM sys.dm_exec_query_stats AS qs
CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) AS st
ORDER BY qs.total_worker_time DESC;

This example is a starting point, not a universal monitoring query.

Remember its scope:

• it reflects plans currently represented in cache;
• a restart, recompile or eviction can remove history;
• total cost and average cost answer different questions;
• one rare but terrible query and one tiny query executed millions of times create different business problems.

Useful ranking perspectives include:

• total CPU;
• average CPU;
• total logical reads;
• average logical reads;
• total elapsed time;
• execution count;
• most recent execution.

---

19. Query hash and plan hash help group evidence

SQL Server exposes identifiers such as query_hash and query_plan_hash.

Conceptually:

• query_hash helps group queries with the same or similar logical shape despite some literal differences;
• query_plan_hash helps identify matching physical plan shapes.

This supports useful investigations:

Same query shape, different plan hashes
The logical request has received different physical strategies

Large execution count under one query hash
A small per-execution cost may still create a major cumulative workload

Hashes are diagnostic grouping tools, not business identifiers, and hash collisions are theoretically possible. Use them with supporting text, plan and timing evidence.

---

20. A slow query may actually be waiting

Elapsed time does not equal CPU time.

A request can spend most of its life waiting for:

• a lock held by another transaction;
• storage I/O;
• memory grant availability;
• parallel worker coordination;
• network consumption by the client;
• log flushes;
• another resource represented by a wait type.

If Session 52 is blocked by Session 41, rewriting Session 52 may not address the immediate cause. You need to understand what Session 41 is doing, how long its transaction has remained open and why the conflicting locks exist.

Blocking is not automatically a defect. Locking protects correctness. The problem may be excessive transaction scope, inconsistent access order, missing supporting indexes, a slow client, or work being performed inside a transaction that should happen outside it.

Treat wait information as a clue about where time is being spent, then connect it to the query, transaction and workload.

---

21. Extended Events: observe targeted behaviour

Extended Events provide a lightweight, flexible mechanism for capturing SQL Server events.

They can help investigate:

• completed statements or batches;
• errors;
• deadlocks;
• long durations;
• excessive reads or CPU;
• recompilation;
• selected optimizer and execution behaviour.

Design an event session around a question. Capturing everything creates overhead and produces noise.

A good diagnostic definition includes:

• the event that answers the question;
• predicates that narrow the workload;
• only the actions and fields required;
• an appropriate target;
• a retention and review plan.

SQL Trace and Profiler remain relevant when reading older material or supporting legacy processes, but Extended Events are normally the better starting point for modern SQL Server diagnostics.

---

22. Plan cache evidence is useful but incomplete

SQL Server can reuse compiled plans, avoiding compilation on every execution. That is valuable, but cached evidence has limitations.

A plan may disappear because of:

• memory pressure;
• recompilation;
• schema or statistics changes;
• explicit cache clearing;
• service restart;
• natural cache eviction.

Do not clear the entire plan cache casually in production. It affects unrelated workloads and can create a burst of compilation.

When persistent history matters, Query Store and an established monitoring platform are often more appropriate than relying only on the current cache. Query Store belongs beyond the book's first three chapters, but it is the natural modern continuation of their troubleshooting mindset.

---

23. A practical investigation workflow

When a query is reported as slow, use a repeatable sequence.

Step 1: define the symptom

Record:

• query or operation;
• parameter values;
• expected and actual duration;
• frequency;
• time window;
• affected users;
• whether the problem is current or historical.

Step 2: decide whether it is running or waiting

Inspect active requests, wait type and blocking session information.

Step 3: capture the plan safely

Use an actual plan in a safe test or controlled context when runtime row counts are required. Use cached, estimated or monitored plans where executing the workload again would be unsafe.

Step 4: compare estimated and actual rows

Find the earliest meaningful divergence. Later operators may simply be suffering from an earlier estimation error.

Step 5: measure reads, CPU and duration

Use STATISTICS IO, STATISTICS TIME, runtime metrics and monitoring evidence appropriate to the environment.

Step 6: inspect data access and row flow

Ask:

• How many rows and pages are touched?
• Are predicates selective?
• Are conversions or expressions reducing useful access options?
• Are large intermediate results being created?
• Are lookups repeated many times?
• Are sorts or hashes spilling?

Step 7: inspect metadata and estimates

Check statistics, types, constraints, parameter behaviour and relevant indexes.

Step 8: make one reasoned change

Possible changes include:

• rewriting a predicate;
• correcting a data-type mismatch;
• updating an appropriate statistic;
• adding, changing or consolidating an index;
• reducing selected columns or rows;
• shortening a transaction;
• addressing parameter sensitivity;
• correcting application behaviour.

Step 9: verify the result

Compare before and after using the same meaningful workload. Confirm that the change has not simply moved cost to writes, compilation, memory or another query.

Step 10: monitor after release

Data volume, distribution and concurrency change. A fix is not complete until its production behaviour is observed.

---

24. Common mistakes this mental model prevents

"A seek is always good and a scan is always bad"

A scan can be the right choice when much of a table is required. A seek that triggers millions of lookups can be worse. Judge the complete plan and workload.

"The highest-cost operator is the problem"

Estimated percentages are relative estimates inside one plan. The operator may be expensive because of incorrect row estimates or excessive input from earlier work.

"The query text shows the execution order"

The optimizer can reorder and transform relational operations where semantics permit. Written order does not reliably dictate physical order.

"Add the missing index"

Missing-index suggestions ignore the full cost of index maintenance and overlap. Validate against the whole workload.

"The optimizer chose badly, so force a hint"

First ask whether it received misleading estimates, stale statistics, awkward predicates, mismatched types or insufficient access paths. A forced plan can become tomorrow's incident.

"It was fast on my laptop"

Small data, warm cache, no concurrency and one parameter value do not represent production.

"Clear the cache and see what happens"

Broad cache clearing affects other workloads and destroys evidence. Use targeted, controlled actions only when justified.

---

25. The code-review questions to keep

When reviewing important SQL, ask:

1. What result is the query declaring?
2. Are object names, data types and predicates unambiguous?
3. What facts can constraints and metadata prove?
4. How many rows are likely to flow through each stage?
5. Do estimates match reality?
6. How many pages are read?
7. Is elapsed time CPU work or waiting?
8. Could the same result be produced with less data movement?
9. Is the plan stable across representative parameter values?
10. What evidence will prove the proposed change helped?

These questions are more durable than memorising plan icons.

---

The complete mental model

T-SQL text submitted
        ↓
Parse the language
        ↓
Bind names, types and metadata
        ↓
Build a logical relational tree
        ↓
Simplify what can be proved unnecessary
        ↓
Check whether a trivial plan is sufficient
        ↓
Generate equivalent logical alternatives
        ↓
Map them to physical operators
        ↓
Estimate rows and cost using statistics
        ↓
Search promising alternatives within a budget
        ↓
Select an execution plan
        ↓
Execute through relational and storage engine work
        ↓
Measure actual rows, reads, CPU, duration and waits

The statement you write begins the process. It does not describe the complete process.

---

Final lesson

SQL Server query tuning becomes less mysterious when you stop asking only:

"How can I rewrite this SQL?"

and start asking:

"What did SQL Server understand, what did it estimate, what alternatives could it consider, what did it choose, and what evidence shows where the cost really occurred?"

SQL Server is not simply executing the SQL you typed.

It parses and binds the request. It converts declarative text into logical operations. It simplifies what can be removed. It generates equivalent alternatives. It maps those alternatives to physical operators. It estimates their cost from statistics and metadata. It searches under practical limits, chooses a plan and executes it.

Your role is not to outguess that machinery from memory.

Your role is to give it trustworthy schema information, useful access paths and clearly expressed queries—then measure the work it actually performs.

That is the foundation of professional SQL Server query optimization.

---

Continue learning

This article focuses on the mental model established by the first three chapters of *SQL Server Query Tuning and Optimization*: query processor architecture, evidence-led troubleshooting and the optimizer's search process.

Continue with:

• SQL Mentoring Series — Part 1: Relational Foundations
• SQL Mentoring Series — Part 2: Advanced Querying and Transactional SQL
• SQL Mentoring Series — Part 3: Performance Engineering
• How to Investigate a Slow Angular, ASP.NET Core and SQL Server Application

If this guide helped you understand what happens between submitted SQL and an execution plan, I would be pleased to hear from you at dotnetdeveloper20xx@hotmail.com.