Performance issue in using SELECT *? [duplicate]

Answer 1

If you are only using a subset of the fields, then the performance difference can be substantial. See the following example, which involves retrieving 1,411,771 rows from CScout's analysis of the Linux code.

$ time sh -c "echo 'select * from IDS' | mysql cslinux >/dev/null"
real    0m5.622s
user    0m2.580s
sys     0m0.532s

$ time sh -c "echo 'select EID from IDS' | mysql cslinux >/dev/null"
real    0m4.492s
user    0m0.716s
sys     0m0.096s

An this is not even measuring the performance impact on the server.

Answer 2

If you use select * in a join then you are automatically sending more information than you need becasue the join field(s) are repeated. This is a waste of processing time and network resources and can cause performance problems. Further not specifying the fields means that your application can break when new fields are added especially if they are fields that the user is not intended to see but which are there for auditing or database type processing. Select * in an insert is always a bad idea as somewhere along the line some somen who is less than smart may actually change the order of the columns in the table .

Answer 3

I don't know about computing performance but in terms of read/maintain-ability (i.e. Human Performance) we don't use select * at my shop. Everything is explicitly selected.

Answer 4

Supposedly yes. I'm whole-heartedly told at work that I should never use SELECT *. In fact, it's in our policy not to use it because a) it means there's ambiguity in what is used and what's available just by looking at the query and b) it's slower as the SQL server has to find each column it needs and return them.

I've never seen any proof of this, however.

EDIT: Also, if a stored procedure is compiled on the server and uses SELECT *, when the underlying table structure changes supposedly it won't select back the newly introduced columns as SQL compiles SELECT * down to the individual columns.

Answer 5

If all fields are specified, then no, there shouldn't be a meaningful difference performance-wise. But if you just want a couple specific fields from a table with a dozen columns, it's slower.

There are readability and maintainability issues with SELECT *. It makes sense to use specific field names all the time, even if you want to select all fields.

Answer 6

I will echo what others have said regarding "select *" retrieving a list of columns as part of the request handling. By contrast, you can also select columns by ordinal, which saves even more time since the RDBMS engine doesn't even need to look up the column to determine the position of the column to retrieve. I find this highly useful for aggregate queries.

For example: select count(1) from ... versus select count(*) from ...

In this example, the RDBMS only needs to know that it needs the count of the first column, and ZING, it's off. In the (unfortunately) more common select count(*), the RDBMS retrieves a list of all the columns, and then verifies each row to determine if it's valid for counting (as opposed to validating the 1st column only).

This works great most of the time. I'm pretty sure most DB systems count NULL values in the count, but you should watch out for this and verify before assuming.

YMMV, void where prohibited, etc.!