5

As someone who is newer to many things SQL as I don't use it much, I'm sure there is an answer to this question out there, but I don't know what to search for to find it, so I apologize.

Question: if I had a bunch of rows in a database with many columns but only need to get back the IDs which is faster or are they the same speed?

SELECT * FROM...

vs

SELECT ID FROM...
marc_s
  • 732,580
  • 175
  • 1,330
  • 1,459
zezba9000
  • 3,247
  • 1
  • 29
  • 51

4 Answers4

4

You asked about performance in particular vs. all the other reasons to avoid SELECT *: so it is performance to which I will limit my answer.

On my system, SQL Profiler initially indicated less CPU overhead for the ID-only query, but with the small # or rows involved, each query took the same amount of time.

I think really this was only due to the ID-only query being run first, though. On re-run (in opposite order), they took equally little CPU overhead.

Here is the view of things in SQL Profiler:

SQL Profiler Results - *, ID-Only, ID-Only, *

With extremely high column and row counts, extremely wide rows, there may be a perceptible difference in the database engine, but nothing glaring here.

Where you will really see the difference is in sending the result set back across the network! The ID-only result set will typically be much smaller of course - i.e. less to send back.

J0e3gan
  • 8,740
  • 10
  • 53
  • 80
3

Never use * to return all columns in a table–it’s lazy. You should only extract the data you need. so-> select field from is more faster

Abhi Adr
  • 1,264
  • 2
  • 11
  • 27
2

There are several reasons you should never (never ever) use SELECT * in production code:

  1. since you're not giving your database any hints as to what you want, it will first need to check the table's definition in order to determine the columns on that table. That lookup will cost some time - not much in a single query - but it adds up over time.

  2. in SQL Server (not sure about other databases), if you need a subset of columns, there's always a chance a non-clustered index might be covering that request (contain all columns needed). With a SELECT *, you're giving up on that possibility right from the get-go. In this particular case, the data would be retrieved from the index pages (if those contain all the necessary columns) and thus disk I/O and memory overhead would be much less compared to doing a SELECT *.... query.

Amarnath Balasubramanian
  • 9,300
  • 8
  • 34
  • 62
1

Long answer short, selecting only the columns you need will always be faster. SELECT * requires scanning the whole table. This is a best practice thing that you should adopt very early on.

For the second part, you should probably post a seperate question instead of piggybacking off this one. Makes it easy to distinguish what you are asking about.

TTeeple
  • 2,913
  • 1
  • 13
  • 22