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 over the network.

This increases network traffic and slows down data transfer.

In high-throughput systems this effect can become surprisingly significant.

2. Poor Index Usage

SELECT * can also prevent SQL Server from using optimal indexes.

Imagine a query like this:


SELECT *
FROM Orders
WHERE CustomerID = 100

Even if an index exists on CustomerID, SQL Server may still need to access the base table to retrieve the remaining columns.

This often leads to expensive operations such as:

Key Lookups
Clustered Index Lookups

The more rows returned, the more expensive these lookups become.

3. Covering Indexes Become Impossible

One of the most effective SQL Server performance techniques is the covering index.

A covering index contains all the columns needed by a query.

This allows SQL Server to answer the query directly from the index without accessing the base table.

For example:


SELECT OrderDate, TotalAmount
FROM Orders
WHERE CustomerID = 100

You could create a covering index like this:


CREATE INDEX IX_Orders_CustomerID
ON Orders(CustomerID)
INCLUDE (OrderDate, TotalAmount)

But when the query uses SELECT *, creating a covering index becomes almost impossible.

You would need to include every column in the table.

Clearly that is not a practical solution.

4. Schema Changes Become Dangerous

Another hidden problem with SELECT * is maintainability.

When new columns are added to a table, SELECT * automatically includes them in the result set.

This can create unexpected issues in applications.

For example:

larger result sets
broken data mappings
unexpected application behavior

Explicit column lists make queries much more predictable.

The Better Approach

Instead of using SELECT *, specify exactly which columns you need.

For example:


SELECT OrderDate, TotalAmount
FROM Orders
WHERE CustomerID = 10

This simple change improves:

query performance
index efficiency
network usage
application stability

The Real Lesson

SELECT * is convenient during development.

But in production systems it often hides performance and maintainability problems.

Writing explicit column lists is a small habit that can significantly improve SQL Server performance.

And remember…

No SQL Server was harmed while writing this SELECT statement 😉

See you in the next SQL Server performance deep dive!

Search This Blog

SQL Server Performance Blog where milliseconds matter