To preface, I’m aware (as should you!) that using SELECT * in production is bad, but I was maintaining a script written by someone else. And, I’m also aware that this question is low on specifics… But hypothetical scenario.
Let’s say I have a script that selects everything from a table of 20 fields. Let’s say typical customer information.
Then let’s say being the good developer I am, I shorten the SELECT * to a SELECT of the 13 specific fields I’m actually using on the display end.
What type of performance benefit, if any, could I expect by explicitly listing the fields versus SELECT *?
I will say this, both queries take advantage of the same exact indexes. The more specific query does not have access to a covering index that the other query could not use, in case you were wondering.
I’m not expecting miracles, like adding an index that targets the more specific query. I’m just wondering.
It depends on three things: the underlying storage and retrieval mechanism used by your database, the nature of the 7 columns you’re leaving out, and the number of rows returned in the result set.
If the 7 (or whatever number) columns you’re leaving out are “cheap to retrieve” columns, and the number of rows returned is low, I would expect very little benefit. If the columns are “expensive” (for instance, they’re large, or they’re BLOBs requiring reference to another file that is never cached) and / or you’re retrieving a lot of rows then you could expect a significant improvement. Just how much depends on how expensive it is in your particular database to retrieve that information and assemble in memory.
There are other reasons besides speed, incidentally, to use named columns when retrieving information having to do with knowing absolutely that certain columns are contained in the result set and that the columns are in the desired order that you want to use them in.