I heard that there are many people who prohibit developers from using SELECT * in SQL, which translates a stackoverflow question, which is personally considered to be quite objective
The "SELECT *" Hazard mainly includes the following points:
- Inefficient data transmission to consumers. When you select * often you will query from the database more than your application function actually need too many columns, which may also lead to redundant data from the data to the server to the client, resulting in increased machine burden, the same network transmission will increase the burden. Especially when a new column is added to the data table, but the feature implementation is not needed at all.
- Index issues. Imagine such a scenario: you need to tune a query to a certain high performance. If you use a SELECT * and then return all columns that exceed the columns you need, the server often needs to consume more of the cost of your data than it would otherwise have. For example, you can't simply create an index that overrides all of the columns you select, even if you do (including all columns, it's scary), the next dig deceptive and add new columns to the datasheet, causing the index you already covered to not be optimized. Then you'll be amazed to see that your query performance pops down without obvious reasons.
- Binding issues. When you select *, it is possible to query for columns from two tables but with the same name. This may cause the data binding end or function point to crash, think back to have two columns of data is ID, who TM know which column? SELECT * may also disrupt views (partial databases, versions)--when the underlying data table structure changes and the view is not new, the view's data may return meaningless data (the name is poorly maintained?). ）。 Worst of all, you can toss the column that you named, but the new dig deceptive to join the column, don't know how he should name the column name will not conflict with the column name you have buried well.
About the endangerment of select * (asterisk) in SQL
