HiveBrain v1.2.0
Get Started
← Back to all entries
patternsqlCritical

Is select * still a big no-no on SQL Server 2012?

Submitted by: @import:stackexchange-dba··
0
Viewed 0 times
2012stillsqlbigserverselect

Problem

Back in the days of yesteryear, it was considered a big no-no to do select from table or select count() from table because of the performance hit.

Is this still the case in later versions of SQL Server (I'm using 2012, but I guess the question would apply to 2008 - 2014)?

Edit: Since people seem to be slating me slightly here, I'm looking at this from a benchmark/academical point of view, not whether it's the "right" thing to do (which of course it's not)

Solution

If you SELECT COUNT(*) FROM TABLE that only returns one row (the count), is relatively light, and is the way to get that datum.

And SELECT * is not a physical no-no, in that it is legal and allowed.

However, the problem with SELECT * is that you can cause a lot more data movement. You operate on every column in the table. If your SELECT only includes a few columns, you might be able to get your answer from an index or indexes, which reduces the I/O and also the impact on the server cache.

So, Yes it is recommended against as a general practice because it is wasteful of your resources.

The only real benefit of SELECT * is not typing all the column names. But from SSMS you can use drag and drop to get the column names in your query and delete those that you do not need.

An analogy: If someone uses SELECT * when they do not need every column, would they also use SELECT without a WHERE (or some other limiting clause) when they do not need every row?

Context

StackExchange Database Administrators Q#69361, answer score: 50

Revisions (0)

No revisions yet.