Performance issue in using SELECT *? [duplicate]

Answer 1

If your embedding sql in code then your should always use the long form for clarity, not performance. For ad-hoc queries the select * syntax is ESSENTIALLY no less efficient than specifying column names unless you have a massive number of columns which you shouldn't unless you're denormalizing.

I should get 1 point for using 2 unlesses in a sentence and still habving it make sense!! :)

Answer 2

Technically, it would depend on the relational database management system you are using. I think the performance hit would be microseconds. If you are absolutely trying to squeeze the last bit of performace out of your system, I would say don't use them.

I personally use it all the time.

Answer 3

Performance, not much. It's just a bit clumsy: in a table, say, with 10 columns, joined on two other tables or even more, particularly with large result sets, SELECT * can return dozens of columns, often with mostly unused or even useless data. In terms of the hit on the DBMS, there wouldn't be much, but all that data still needs to travel across the wire somehow; network bandwidth and consequent latencies certainly add up. I've seen this first-hand in high-volume environments. It definitely matters.

Aside from the bandwidth issues, you can also run into ambiguous column-naming problems (disambiguating usually means removing SELECT * anyway, so you might as well do it from the start), and it's also considered good practice to be explicit about the needs of the code inside the code; doing so helps in lots of ways -- with debugging, with collaborating, etc.

Answer 4

If you need a subset of the columns, you are giving bad help to the optimizer (cannot choose for index, or cannot go only to index, ...)

Some database can choose to retrieve data from indexes only. That thing is very very helpfull and give an incredible speedup. Running SELECT * queries does not allow this trick.

Anyway, from the point of view of application is not a good practice.

---

Example on this:

• You have a table T with 20 columns (C1, C2, ..., C19 C20).
• You have an index on T for (C1,C2)
• You make SELECT C1, C2 FROM T WHERE C1=123
• The optimizer have all the information on index, does not need to go to the table Data

Instead if you SELECT * FROM T WHERE C1=123, the optimizer needs to get all the columns data, then the index on (C1,C2) cannot be used.

In joins for multiple tables is a lot helpful.

Answer 5

Every time you do a select *, there is may be an additional query to get the list of columns. In high transaction environments this could become a visible overhead, but once every now and then will make no difference.

Also, when inserting records, never use select * in an insert in case columns are added.

Answer 6

The only performance issue will be if your application only needs a subset of the fields returned by select *. There is no performance difference in the database as they are effectively the same thing.