Skip to main content

Why not use Select * in SQL Server

 
Select *

We often use the Select * to fetch data from tables of SQL Server.

Today, we will see why we should avoid Select *


Figure: Imagine yourself handcuffed while writing Select *

I will be using AdventureWorks2019 Database for demonstration.

First, we do the following -

Set Statistics IO ON;

This will output us how many 8 KB pages SQL server read for our request.

Let's use Sales.SalesOrderDetail table. We use the following query : 

Select * 

from Sales.SalesOrderDetail

set statistics IO ON

set statistics IO ON output


We get the result tab and Message tab. If we look into the Message tab, we get -

(121317 rows affected)

Table 'SalesOrderDetail'. Scan count 1, logical reads 1248, physical reads 0, page server reads 0, read-ahead reads 0, page server read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob page server reads 0, lob read-ahead reads 0, lob page server read-ahead reads 0.

Ok! SQL Server had to read 1248 - 8 KB pages. you might know, there are 500 pages in a ream of paper. so SQL server had to go through almost 2.5 reams of paper!

Now, Let's modify our query to select 2 columns

select SalesOrderDetailID, SalesOrderDetailID

from Sales.SalesOrderDetail 

Similarly, We get the result tab and Message tab. If we look into the Message tab, we get -

(121317 rows affected)

Table 'SalesOrderDetail'. Scan count 1, logical reads 276, physical reads 1, page server reads 0, read-ahead reads 288, page server read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob page server reads 0, lob read-ahead reads 0, lob page server read-ahead reads 0.



Now, SQL server had to read 276 - 8KB pages, only about half a ream of paper.

Definitely, that's a relief.

Can I use Select * for tables with few columns?

 If you need all the columns, select each of the column names instead, Why?

Let's say you have 3 columns on your table, so you decided to Select * instead of writing the names of the column. 2-3 years later, you find out, all other developers have added some columns to the table and the table contains 10/12 columns, and your Select * query that you wrote 3 years ago, is paying off heavily on production server now. So, stay away from the mistake you will probably regret 3 years later.

What can happen if I use Select *

Select * can lead to more processing effort to SQL Server and in case of parallel plan execution enabled, you may face Threadpool - a deadly poison wait for SQL Server

No worries, to get rid of this deadly wait, all you need is setting your MaxDop and Cost threshhold for parallelism Properly 

Remember, the best way to deal with your SQL Server is to think like SQL Server and using the best configuration for your System.


Comments

  1. Very informative and easy to CATCH!
    Keep it up sir :)
    Jazakallah :)

    ReplyDelete
    Replies
    1. I am pleased that you liked it. Stay tuned for more of my SQL Server Pain Reliefs !

      Delete

Post a Comment

Most Loved Posts

SQL Data Tools - Compare Data

Compare Data between two tables SQL Server Database with the same schema architecture can differ in different environments like Dev, Staging, and Production, especially in configuration tables. Let's see how we can easily sync the data in two different tables.

Threadpool - A deadly poison wait for SQL Server (The What, When and How)

Introduction  Threadpool is a  poison  wait. Yes, I mean it. Its poison for SQL Server, its poison for the Business and of course, the end-users! The most devastating thing about threadpool is you hardly recognize it because it comes in disguise, meaning you see no memory or cpu pressure in the system, yet you cannot run any query, it seems like your SQL Server is frozen solid. That scary, isn't it?

How to Backup SQL server like Batman: The Ultimate SQL DBA Guide

Slow SQL Server : What we should NOT do

 Try to list the best practices of SQL Server. It will require a heck of a time. Try to list the Bad Practices and it will require more than the best practice list , of course, probably you’ll end up getting frustrated . (seeing all the oops configurations and its effect on SQL Server )

How to configure your Availability Group listener to ASP.NET

SQL Server’s availability group Always On feature is great to have features for your Database. Anytime one of your database nodes goes down, your secondary replica will automatically take over. After a failover, your secondary cluster node becomes the primary cluster. Now the question arises, “Do I need to configure my APP server connectionstring each time I face a failover cluster?”. The answer is NO, you don’t have to configure your app server connectionstring every time. Default ConnectionString By default, your App server connectionstring looks something like this – <connectionStrings>    <add name="ConnStringDb1" connectionString="Data Source=localhost;Initial Catalog=YourDataBaseName;Integrated Security=True;" providerName="System.Data.SqlClient" />   </connectionStrings> ConnectionString for Failover Partner You can manually specify the failover partner in your connectionstring like this <connectionStrings>     <a...

Intelligent Query Processing in SQL Server 2019 Big Data

SQL Server 2019: Intelligent Query Processing SQL Server 2019 ships with some brand-new features. Many of these features are targeted for Big Data Solutions. No wonder in that, since the world is moving faster towards Big Data and it is absolutely necessary to cope up with that. Today we will discuss one such feature called Approximate Query Processing. Approximate Query Processing SQL Server ships with Intelligent Query Processing out of the box with SQL Server 2019 installation. Approximate Query processing is a part of Intelligent Query Processing. Things we will be covering in this article – Understand the need for Approximation with Case Study Case Study 1: Railway Case Study 2: e-commerce How to use Approximate Query Processing Demo Code for Comparing Performance Results Limitations When to avoid Approximate Query Processing Understand the need for Approximate Query Processing Before using any technological feature, we must understand why we should use it? Should we jus...

6 Letters for SQL Disaster Emergencies : RPO and RTO

 

SQL Server Performance : OR vs UNION ALL

When writing queries, we seem to care less about the performance issue at first. Our first goal is to make the output right. When we get the correct output, we then move on to the next phase we call performance tuning. Today we will try to understand what happens when you write OR in your query. We will do the same thing with UNION ALL and try to understand which one seems to perform better.