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

Yes it does. Basically:

• More data has to be transfered from your database server
• The database server has to fetch more data

You shouldn't use select *

Answer 2

SELECT * is usually never a good idea. It may not slow down your DBMS fetch a lot but it will probably result in more data being transmitted over the network than you need.

However, that's likely to be swamped into insignificance by the use of the LIKE '%frank%' clause which is basically non-indexable and will result in a full table scan.

You might want to consider cleaning up the data as it enters the database since that will almost certainly make subsequent queries run much faster.

If you're after frank, then make sure it's stored as frank and use:

select x,y,z from table where name = 'frank'

If you want to get franklin as well, use:

select x,y,z from table where name like 'frank%'

Both of these will be able to use an index on the name column, "%frank%" will not.

Answer 3

If remember correctly from college (and its been awhile), selecting * is not prefered, but not that bad -- until you start joining. When you get into the relational alegbra of creating the joined tuples, every column adds to time, so I would definately avoid it if possible.

Answer 4

Let me play devils advocate and suggest a scenario where SELECT * is a better choice. Suppose you are creating a user interface where you take the results of the dataset and display it in some form of table or grid. You could build the columns in the UI to match the columns in the dataset and do the SELECT * FROM MyView.

By using a View in the database you have complete control over what columns are returned by the query and the UI can by dynamic enough to display all of the columns. Changes to the view would be reflected immediately in the UI without recompiling and re0 Obviously I would suggest following the previous advice and specify all of the columns in the view definition.

Just thought I would add that as sometimes people get dogmatic about following certain rules and forget that context matters.

Answer 5

If person only has Id, Forename, and Surname, the queries should be equivalent. However, the query time will grow proportionately to the number of column (really amount of data) returned.

Also, if query will only ever need those three columns, you should only ask for those three. If you SELECT * and you change your schema later, you're basically just adding extra processing to all of your queries with not real added benefit.

Answer 6

There are multiple dimensions to this. For once the * will make your code more fragile. When in later versions you change table layouts code that relies on column order might break - or might not but read or modify the wrong columns if the data types still match which can be a really nasty problem!

Moreover if you always request all columns you will require more memory on your database client and the database server for the unneeded columns. This can be really expensive if the table contains long character fields, very many fields and/or BLOBs. Selecting unnecessary columns will also thrash the server's cache by flooding it with superflous contents that is never looked at by a client.

So in general you should not use it. Most object relational mapping tools generate SQL that contains all column names anyway, so during development this is probably not an issue anyway. I personally only tend to use * for quick ad-hoc queries that I have to type manually.