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

In addition to the other answers, consider that SELECT * will return data from all tables in the query. Start adding other tables through JOINs, and you'll start seeing things you don't want to see.

I believe I've also seen cases where SELECT * requires data actually be fetched from a joined table, as opposed to only using the indexes on that table to help narrow down the overall result set. I can't think of an example of that, though.

Answer 2

Sure. Better name the columns you want to retrieve.

Answer 3

The number of columns in the table does not affect the performance of your query. The number of columns operated upon in the query will.

Note the following example from the Oracle concepts manual:

Row Format and Size Oracle stores each row of a database table containing data for less than 256 columns as one or more row pieces. If an entire row can be inserted into a single data block, then Oracle stores the row as one row piece. However, if all of a row’s data cannot be inserted into a single data block or if an update to an existing row causes the row to outgrow its data block, then Oracle stores the row using multiple row pieces. A data block usually contains only one row piece for each row. When Oracle must store a row in more than one row piece, it is chained across multiple blocks.

When a table has more than 255 columns, rows that have data after the 255th column are likely to be chained within the same block. This is called intra-block chaining. A chained row’s pieces are chained together using the rowids of the pieces. With intra-block chaining, users receive all the data in the same block. If the row fits in the block, users do not see an effect in I/O performance, because no extra I/O operation is required to retrieve the rest of the row.

HOWEVER: If there are 400 columns, I would bet that most rows will not fit in one block and hence you will see a lot more 'db file sequential read' than normally required. As well, I remember that Steve Adams (or someone long ago) mentioning that there is an additional cost for accessing a column "further down the list" - sorry don't have that link.

Answer 4

For small projects, you can usually get away with select *. It's "right" to not do that, though. You won't notice any appreciable speed difference for one table in a non-index query... the only thing you're appreciably doing is using more bandwidth for columns you don't read.

That said, you will notice a difference in index-only queries where you're hitting the full table when you only needed to hit the index. This will especially crop up when you're doing joins.

Select * does have uses though, and if you use it properly (say, in combination with a cache, making sure it's select table.*, and addressing results by column name) you can reduce queries made by your application.

Answer 5

You better avoid SELECT *

• It leads to confusion when you change the table layout.
• It selects unneeded columns, and your data packets get larger.
• The columns can get duplicate names, which is also not good for some applications
• If all the columns you need are covered by an index, SELECT columns will only use this index, while SELECT * will need to visit the table records to get the values you don't need. Also bad for performance.

Answer 6

I would visit this question on why using the "Select * " construct is not preferred.

In my experience selecting 3 columns versus select * in a 3 column table might not have a noticeable impact performance wise but as tables get larger and wider you will notice a performance difference.