Is there a difference between Select * and Select [list each col] [duplicate]

Answer 1

The two sides of the issue are this: Explicit column specification gives better performance as new columns are added, but * specification requires no maintenance as new columns are added.

Which to use depends on what kind of columns you expect to add to the table, and what the point of the query is.

If you are using your table as a backing store for an object (which seems likely in the LINQ-to-SQL case), you probably want any new columns added to this table to be included in your object, and vice-versa. You're maintaining them in parallel. For this reason, for this case, * specification in the SELECT clause is right. Explicit specification would give you an extra bit of maintenance every time something changed, and a bug if you didn't update the field list correctly.

If the query is going to return a lot of records, you are probably better off with explicit specification for performance reasons.

If both things are true, consider having two different queries.

Answer 2

Its good for forward-compatiblity.

When you use

SELECT * FROM myTable

and in "myTable" are 3 columns. You get same results as

SELECT Column1, Column2, Column3 FROM myTable

But if you add new column in future, you get a diferent results.

Of course, if you change name one of existing column, in first case you get results and in the second case you get a error ( I think, this is correct behaviour of application ).

Answer 3

If your code relies on certain columns being in a certain order, you need to list the columns. If not, it doesn't really make a difference if you use "*" or write the column names out in the select statement.

An example is if you insert a column into a table.

Take this table: ColA ColB ColC

You might have a query:

SELECT *
FROM myTable

Then the code might be:

rs = executeSql("SELECT * FROM myTable")
while (rs.read())
    Print "Col A" + rs[0]
    Print "Col B" + rs[1]
    Print "Col C" + rs[2]

If you add a column between ColB and ColC, the query wouldn't return what you're looking for.

Answer 4

An example as to why you never (imho) should use SELECT *. This does not relate to MSSQL, but rather MySQL. Versions prior to 5.0.12 returned columns from certain types of joins in a none-standard manner. Of course, if your queries defines which columns you want and in which order you have no problem. Imagine the fun if they don't.

(One possible exception: Your query SELECTs from just one table and you identify columns in your programming language of choice by name rather than position.)

Answer 5

I'm going to get a lot of people upset with me, but especially if I'm adding columns later on, I usually like to use the SELECT * FROM table. I've been called lazy for this reason, because if I make any modifications to my tables, I'd like not to track down all the stored procs that use that table, and just change it in the data access layer classes in my application. There are cases in which I will specify the columns, but in the case where I'm trying to get a complete "object" from the database, I'd rather just use the "*". And, yes, I know people will be hating me for this, but it has allowed me to be quicker and less bug free while adding fields to my applications.

Answer 6

Some reasons not to use the first statement (select *) are:

1. If you add some large fields (a BLOB column would be very bad) later to that table, you could suffer performance problems in the application
2. If the query was a JOIN query with two or more tables, some of the fields could have the same name. It would be better to assure that your field names are different.
3. The purpose of the query is clearer with the second statement from an programming esthetics viewpoint