Performance issue in using SELECT *? [duplicate]

Answer 1

SELECT * requires SQL to find all the column names however this is not the biggest performance hit by a long shot.

The biggest performance hit of a SELECT * statement is when you are performing a query which requires a Nonclustered index to evaluate. Even if the nonclustered index is a covering index of every column, SQL will still look up the primary key and get the values from the clustered index.

On top of this, if you only need one or two columns, you have the network bottleneck to deal with due to returning a bigger result set than required.

Answer 2

I agree with just about all the answers except certain performance claims. If you are actually going to use all the columns in the table, I'd argue the SELECT * version is a smidgen faster. Here's why:

Take these two queries on a table where there is a unique index on (id,x):

SELECT x,y,z,w FROM tab WHERE id='abc' ORDER BY s

SELECT x,y,z,w FROM tab WHERE id='abc' 
AND x in ('a','b','c','d','e','f','g','h',...)
ORDER BY ('a','b','c','d','e','f','g','h',...)

Which is faster? If the 'x in' clause names all the values for x in the table for id 'abc' then the first query is probably faster. Now let's rename these fields:

SELECT field_name, field_type, field_offset, field_len
FROM internal_field_catalog
WHERE table_name = 'abc'
ORDER BY field_order

So when retrieving the data, the SELECT * allows the engine to do (the equivalent of) a single memcpy to move the row data to the result set and when retrieving the field data it probably is selected faster.

All I'm saying is there is an edge case where SELECT * is perfectly useful and probably faster. One reason you might always need all columns from a table is when storing object persistence in an RDBMS (for some reason). To every rule of thumb there is an exception.

Answer 3

Take a look at this post:

What is the reason not to use select *?

and these:

• Performance benefit when SQL query is limited vs calling entire row
• Which is faster or best, select * or select column1 colum2 column3
• SQL query question select * from view or select col1 col2 col3 from view
• Which is faster, select * or select column1 column2 etc

Answer 4

Performance This will always be bad if you do not NEED all the columns. Returning more data than is needed will throttle the database and your lan/wan bandwidth.

Readability Knowing which columns are in the view, procedure can be very useful , SELECT * is not helpful at all and I would consider it counter-productive.

*Testing If you make a schema change, all your code that use SELECT * within should be invalidated because any tests you write to check metadata should check the output of the view, proc.

*Of course, assuming you have tests in place as all good DB Dev's should have :)

Answer 5

I'm not a DBA, but from what I recall learning from our DBA, the reasoning (at least with SQL Server) is that the DB caching algorithms don't cache '*' queries well, but if you are running the same query with exact columns specified multiple times, it will cache that well.

I'm sure a more knowledgeable DBA could go into the exact details of how the caching mechanism works, but that's why there is a performance hit.

NOTE: Caching performance only works if the query is going to be run multiple times, especially in a small time frame, so otherwise you would see no performance difference.

Answer 6

Maybe. It depends largely on the database engine, how it stores stuff, how many rows are coming back, how many other columns there are and the sizes of the other columns.

If you are using a row-based database (i.e. most of them) which stores all the columns together (almost all do, except for BLOBs which are often stored separately, especially the larger ones), then doing SELECT * has little impact on the server itself - it has to fetch the entire row anyway.

On the other hand, if you're sending the data over a network (or even locally, as it'll impact the size of buffers used etc), then it may help to have fewer columns, as there will be fewer bytes to send back. This difference could be dwarfed anyway by server performance if the query is in any way difficult (e.g. requires IO).

If you have big blobs in the rows, SELECT * is not very clever - otherwise, it's unlikely to make much difference, but could.

There are a few "column based" database engines knocking around - they are completely different - for them, "SELECT *" is a total performance killer; be sure to avoid it. The chances are, if you're using one, you are completely aware of this though (typically they're used for very large datawarehouse apps).

For me, the main advantage of not using "SELECT *" is maintainability. You get no surprises when someone adds extra columns to the table; your query "fails fast" when someone removes one of the columns you were using. It makes the code more self-documenting as someone can casually see what columns you wanted.