Posts

JSON Vs. XML! The wrong choice can influence the success or the fail of your project!

Image
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...
Post a Comment
Read more

SQL Server Performance Weekly Recap – What You Might Have Missed This Week!

Image
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...
Post a Comment
Read more

Why SELECT * Is Still Killing SQL Server Performance in 2026?

Image
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...
Post a Comment
Read more

The Most Common SQL Server Indexing Mistake (And How to Fix It)

Image
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...
Post a Comment
Read more

The SQL Server Index Strategy That Works 90% of the Time!

Image
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...
Post a Comment
Read more

Why Your SQL Server Query Is Fast in SSMS but Slow in Production

Image
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 ...
Post a Comment
Read more

SQL SERVER: Read a EXECUTION PLAN in 10 MINUTES!!!

Image
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...
Post a Comment
Read more

The SQL Server Execution Plan Operators that Secretly Kill Performance!

Image
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: ...
Post a Comment
Read more

SQL Server Performance Tuning! ...a SQL Server tuning story: Avoid That Damn Table Spool!

Image
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 ...
Post a Comment
Read more

The SQL Server Query That Looks Fast ….Until It Hits Production. Why?

Image
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...
Post a Comment
Read more

SQL Server Performance Weekly Recap – What You Might Have Missed This Week!

Image
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...
Post a Comment
Read more

SQL SERVER! SARGability: the One Concept You Absolutely Must Understand!

Image
Hi SQL SERVER Guys, Welcome back to this series about the most important concepts about performance! If you care about SQL Server performance, you cannot miss this post becuase there is one concept you absolutely must understand: SARGability . In a previous post I showed how dangerous some SQL queries can be for performance: The Most Dangerous SQL Server Query Today we look at one of the most important techniques to write faster queries: the SARGable way . What does SARGable mean? SARGable stands for Search ARGument ABLE . It means SQL Server can use an index efficiently to find rows. When a predicate is SARGable SQL Server can perform an: Index Seek (fast) When it is not SARGable SQL Server often performs an: Index Scan (slow) A classic NON-SARGable query SELECT * FROM Orders WHERE YEAR(OrderDate) = 2024; This query looks simple, but it hides a performance problem. Because the column is wrapped in the function YEAR() , SQL Serve...
Post a Comment
Read more

The Most Dangerous SQL Server Query Pattern Nobody Talks About ... a foundamental post

Image
The Most Dangerous SQL Server Query Pattern Nobody Talks About ... SQL Server Performance Series – Hidden Performance Killers Hi SQL SERVER Guys, Today we talk about a query pattern that silently destroys performance in many SQL Server systems. If you lost my last post, just click here to enjoy it...  previous post It does not look dangerous since: It compiles fine. It returns the correct results. It passes code review. But under the hood  it forces SQL Server to ignore indexes and scan massive amounts of data . And the worst part? Many developers do not even realize they are doing it. Let's look at the pattern. The Pattern A function applied directly on a column inside the WHERE clause. SELECT * FROM Orders WHERE YEAR(OrderDate) = 2025; Looks harmless. But this single line forces SQL Server to evaluate the function for every row. That means the index on OrderDate becomes useless. Why This Is Dangerous When SQL Server s...
Post a Comment
Read more

Why Most Developers Should Stop Using XML in SQL Server!

Image
Why Most Developers Should Stop Using XML in SQL Server SQL Server Performance Series – Understanding the Cost of Modern Data Formats Previous article: JSON vs XML Indexing – Which One Really Performs Better?   Hi SQL SERVER guys, today we talk about something that may sound controversial. XML in SQL Server. For years it was considered the "enterprise" way to store structured documents. And it was true but modern workloads are changing. And due to this reason in many cases XML is now the wrong choice. Of course, this does not mean XML is useless. But it does mean that most developers still use it without understanding the real performance cost. So let's break it down. Why Developers Loved XML When SQL Server introduced native XML support, it solved many real problems. Hierarchical data representation Schema validation Powerful XQuery language Integration with enterprise systems For complex documents it was a big step forward...
Post a Comment
Read more