SQL Server Performance Blog where milliseconds matter

Good to Know: What Is SQL Server LocalDB? 🧠 SQL Server Internals Series – LocalDB Explained Hi SQL Server Guys, Here is something that many developers use every day without really thinking about it: SQL Server LocalDB. LocalDB is an ultra-lightweight version of Microsoft SQL Server designed specifically for developers. It is perfect for scenarios like: local development environments testing and experimentation desktop applications quick prototypes The interesting part is that LocalDB is not a different database engine. It actually uses the same SQL Server engine used by full SQL Server installations. Key Characteristics of LocalDB SQL Server LocalDB was designed to be extremely simple to use. Unlike a traditional SQL Server installation, LocalDB: runs in user-mode does not require a Windows service starts automatically on the first connection uses the same SQL Server engine This makes it extremely convenient for developers who just ...

SQL Server Performance: JSON vs XML – Which One Is Faster? SQL Server Performance Series – JSON vs XML Hi SQL Server Guys, In performance discussions, usually a very important question came up: Should we use JSON or XML in SQL Server? At first glance this may look like a simple design decision. But in real production systems the choice between JSON and XML can have a significant impact on performance, scalability, and maintainability . In many projects, choosing the wrong format can introduce unnecessary overhead and slow down critical queries . In other words, the decision between JSON and XML can directly influence the success of the system we are building. That is exactly why this comparison is so important. Let’s look at what happens when we compare JSON and XML in SQL Server. JSON vs XML Performance Test By doing internal tests comparing JSON and XML processing, the results i got were quite interesting. When parsing and retrieving values f...

SQL Server Performance Weekly Recap – What You Might Have Missed This Week SQL Server Performance Series – Weekly Roundup Hi SQL SERVER Guys, This week on the blog we explored several important SQL Server performance topics. Some of them are fundamental concepts every SQL Server developer should understand. Others show real-world tuning scenarios that happen very often in production systems. If you missed some of the articles, here is a quick recap of the most recent posts published on the blog. Avoid That Damn Table Spool – A SQL Server Tuning Story In this article we analyzed a real-world query optimization scenario where a single execution plan operator was responsible for major performance problems. The culprit? A Table Spool . We explored why SQL Server sometimes introduces this operator and how a small query rewrite can completely change the execution plan and dramatically improve performance. 👉 Read the full article: Avoid That Damn Table...

Why SELECT * Is Still Killing SQL Server Performance in 2026? SQL Server Performance Series – Query Best Practices Hi SQL Server Guys, Every SQL Server developer has heard this advice at least once: Never use SELECT * in production queries. And yet, many applications still use it everywhere. At first glance, SELECT * seems convenient. It saves time when writing queries and automatically returns all columns from a table. But in real production systems, this small shortcut can create serious performance problems. Even in modern SQL Server versions, SELECT * can still negatively affect performance in several ways. 1. Unnecessary Network Cost When you use SELECT *, SQL Server returns every column in the table. But most applications do not actually need all that data. For example: SELECT * FROM Orders WHERE CustomerID = 10 If the Orders table contains 30 columns but the application only needs 3 of them, SQL Server still sends all 30 columns o...

The Most Common SQL Server Indexing Mistake (And How to Fix It) SQL Server Performance Series – Indexing Pitfalls Hi SQL Server Guys, Indexes are one of the most powerful performance features in SQL Server. But they are also one of the most misunderstood. Many developers believe that adding more indexes automatically improves performance. Unfortunately the opposite is often true. One of the most common SQL Server performance problems I see in real systems is a database full of unnecessary or poorly designed indexes. Today we look at the most common SQL Server indexing mistake and how to fix it. The Real Problem: Too Many Indexes In many databases you will find tables with a surprising number of indexes. Sometimes ten. Sometimes twenty. Sometimes even more. This usually happens because new indexes are added over time whenever a query becomes slow. But very rarely are old or redundant indexes removed. Over time this creates what we could...

The SQL Server Index Strategy That Works 90% of the Time 👌👍 SQL Server Performance Series – Indexing Best Practices Hi SQL SERVER Guys,  Indexing is one of the most important aspects of SQL Server performance tuning. A well-designed index can make a query run in milliseconds. A poorly designed index can make the same query scan millions of rows. The problem is that indexing strategies are often overcomplicated. In reality, a relatively simple approach works in most real-world situations. Today we look at an indexing strategy that works surprisingly well in about 90% of cases. Clustered vs Nonclustered Indexes Every SQL Server table should have a good clustered index . The clustered index defines the physical order of the table data. Without it, SQL Server creates a heap structure, which can lead to inefficient scans and fragmentation. Typical choices for clustered indexes include: primary keys identity columns monotonically increasing...

Why Your SQL Server Query Is Fast in SSMS but Slow in Production? SQL Server Performance Series – Understanding Real World Query Behavior Hi SQL Server Guys, This is one of the most frustrating situations every SQL Server developer eventually faces. A query that runs perfectly fast in SSMS suddenly becomes painfully slow in production. You test it locally. You execute it in SQL Server Management Studio. And the result appears instantly. But when the application executes exactly the same query, performance drops dramatically. What is happening? The answer usually lies in how SQL Server builds and reuses execution plans . 1. Parameter Sniffing One of the most common causes of this problem is something called parameter sniffing . When SQL Server executes a parameterized query for the first time, it creates an execution plan based on the parameter values used during that first execution. SQL Server then caches that execution plan and reuses it ...

How to Read a SQL Server Execution Plan in 10 Minutes! SQL Server Performance Series – Execution Plans Made Simple Hi SQL Server Guys, Execution plans represent the keys to understand SQL Server performance. Unfortunately many developers open an execution plan… look at the colorful icons… and close it immediately. I hear a lot of times these phrases: Too complicated. Too many operators. Too much information. But the truth is that you can learn how to read an execution plan surprisingly fast. In this post I will show you a simple approach that allows you to understand most SQL Server execution plans in about 10 minutes . Step 1 – Always Read the Plan From Right to Left This is the first thing that confuses many developers. Execution plans are read from right to left. The right side shows where the data is coming from. The left side shows the final result returned to the client. Think of the plan as a pipeline of operations that transform data s...

SQL Server Execution Plan ...which Operators Secretly Kill Performance? SQL Server Performance Series – Execution Plan Deep Dive Hi SQL Server Guys, When investigating slow SQL Server queries, many developers focus only on the query text. But the real story is almost always hidden somewhere else. Inside the execution plan . Execution plans is the right place where you must look to understand how SQL Server actually processes a query. And sometimes they reveal operators that silently destroy performance. Today we look at some of the most dangerous execution plan operators. Not because they are always bad, but because when they appear in the wrong context they can cause serious performance problems. 1. Table Spool The Table Spool operator stores intermediate results in a temporary structure. SQL Server does this to avoid recomputing data multiple times. But when the dataset is large, the spool can become extremely expensive. Typical causes: ...

SQL Server Performance Tuning – a SQL Server tuning story: Avoid That Damn Table Spool! SQL Server Performance Series – Execution Plan Deep Dive Hi SQL Server Guys,  Welcome to a SQL Server tuning story. This post is inspired by something that happens very often in real projects: a query that technically works… but performs terribly. During my work I spent a lot of time optimizing queries, sometimes by adding indexes, sometimes by rewriting them. And the interesting part is that sometimes a very small rewrite can completely change the execution plan. Today's example is exactly one of those situations. Enjoy the reading! 👍 PS: In case you missed my last post:  The SQL Server Query That Looks Fast ….Until It Hits Production. Why? The Problem: Table Spool A few days ago I analyzed a query whose execution time was considered too slow by a client. When looking at the execution plan, one operator immediately caught my attention: Table Spool ...

The SQL Server Query That Looks Fast… Until It Hits Production SQL Server Performance Series – Real World Query Pitfalls Hi SQL SERVER Guys,  Today we talk about a query pattern that every SQL Server developer has seen at least once. A query that runs perfectly in development. It returns results instantly. Execution plan looks simple. Everyone thinks the problem is solved. Then the code goes to production. and... ...And suddenly the query that ran in milliseconds now takes seconds… or minutes. What happened? The problem is usually not the query itself. The problem is the data. P.S. if you missed my last post:  SQL Server Performance Weekly Recap – What You Might Have Missed This Week! The Typical Development Query In your development databases typically the amount of data is often very small. Let's say we write something like this: SELECT * FROM Orders WHERE CustomerID = @CustomerID With a few thousand rows this query looks incred...

SQL Server Performance Weekly Recap – What You Might Have Missed This Week! 👌 Hi SQL SERVER Guys, This week we explored some of the most important SQL Server performance topics. Some of them challenge common habits developers have used for years. Others reveal optimization techniques that can dramatically improve query performance. If you missed some of the posts, here is a quick recap of the posts of the week: SQL SERVER! SARGability: the One Concept You Absolutely Must Understand! If there is one concept every SQL Server developer must understand, it is SARGability . A non-SARGable predicate can silently destroy performance by preventing SQL Server from using indexes efficiently. In this article we explored why SARGability matters and how a small rewrite can completely change the execution plan. The Most Dangerous SQL Server Query Pattern Nobody Talks About There is a query pattern that appears perfectly innocent… but can cause huge performan...