Why You Should Avoid SELECT * in Production Queries
SELECT * is convenient during development but causes real problems in production code.
5 Reasons to Avoid SELECT *
1. Performance Overhead
Retrieving unnecessary columns wastes memory, network bandwidth, and I/O. If you need 3 columns but the table has 20, you're moving 17 columns of useless data.
2. Breaks Code When Schema Changes
Adding a new column breaks application code that expects a specific column order. Explicit column names make your code resilient to schema changes.
3. Index Coverage Missed
Databases can serve queries entirely from indexes if you select only indexed columns. SELECT * forces a table access.
-- Can use index-only scan
SELECT user_id, created_at FROM orders WHERE user_id = 123;
-- Forces table access
SELECT * FROM orders WHERE user_id = 123;
4. Hidden Large Columns
Tables often contain BLOB, TEXT, or JSON columns that are expensive to retrieve. You might accidentally fetch megabytes of data you don't need.
5. Security Risk
You might expose sensitive columns (SSN, passwords, internal IDs) that shouldn't be in the result set.
What to Do Instead
-- Bad
SELECT * FROM users WHERE id = 123;
-- Good
SELECT id, name, email, created_at FROM users WHERE id = 123;
Exception: SELECT * is fine for quick ad-hoc queries during development. Just never commit it to production code.