Does the number of columns returned affect the speed of a query?

Question

If I have two queries

SELECT Id, Forename, Surname
FROM Person
WHERE PersonName Like(‘%frank%’)

And

SELECT *
FROM Person
WH         


        

Answer 1

SELECT * will be slower since it has to transfer more data. Also because of some other reasons already mentioned. It really becomes a problem when joining tables since you start adding many more columns, when really all you want to do is join so you can filter.

If you really want to use * , specify the table you want all the columns from, like SELECT Person.* FROM Person...

That will narrow down the amount of data returned and makes it a little more readable.

Answer 2

Generally, in any situation, you want to stay away from using

SELECT * FROM TABLE

in your code. Doing so can lead to several issues, only one of which is performance. Two others I can think of off the top of my head are resource utilization (if you're selecting columns you don't need, or somebody adds columns later...you're bringing back data and wasting memory) and code readability (if somebody sees SELECT * FROM in your code...they're not necessarily going to know which columns are actually being used in your application).

Just a couple of things to think about...but the best practice is NOT to use it.

Answer 3

I'm going to go against the flow here and say you should go with the select *. I think that premature optimization is the root of a lot of problems, and you may well find that it doesn't affect your performance when you get to real utilization. Of course, by the book it is slower, it must be, but that doesn't mean the difference is important in practice.

Something to be aware of, though, is that some SQL engines (MS-SQL for sure) will cache the select *, so if you are using a prepared statement, or a view or stored procedure that has it, and change the table schema, it won't pick up on the change unless the view or sp is recompiled, so that is a good reason to avoid doing it if you aren't running these queries dynamically.

And of course, this varies by database engine, so a little load testing would be in order to make sure the hit isn't obviously large.

Answer 4

Regardless of performance issues, it is good practice to always enumerate all fields in your queries.

• What if you decide to add a TEXT or BLOB column in the future that is used for a particular query? Your SELECT * will return the additional data whether you need it or not.
• What if you rename a column? Your SELECT * will always work, but the relying code will be broken.

Answer 5

the only time i use "select *" is not event really a "select *"

specifically:

select count(*) from table

is not that same as

select count(ID) from table

the first returns the number of rows in the table
but the second returns the number of rows with a NOT NULL ID value.

a subtle distinction but worth remembering.

Answer 6

This is the correct way and the most optimal. The reason is that your only gathering the data needed so it takes up the correct space (What you need) in storing the data before you get your results.

SELECT Id, Forename, Surname
FROM Person
WHERE PersonName Like(‘%frank%’)

This is incorrect as it takes up unused fields which takes up more space to run your query which slows down your results. Even if you get lucky and use all the fields in your query it's best to list them individually. This will clarify the query and what data is to be returned to any other developer who might need to modify the query in the future.

SELECT *
FROM Person
WHERE PersonName Like(‘%frank%’)