Useful Data Tips

Why You Should Avoid SELECT * in Production Queries

⏱️ 30 sec read 📊 SQL

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.

← Back to SQL Tips