Performance

Why SELECT * Kills Performance on Large Tables

SQL Mastery Team
April 24, 2026
5 min read

It's **Day 93**. We've mentioned this before, but now that we know about Covering Indexes and I/O, we can understand **why** `SELECT *` is so destructive.

1. Network Congestion

If a table has 50 columns and you only need 2, you are sending 48 columns of "Trash" over the network. On a busy server, this can saturate your bandwidth.

2. Memory (RAM) Waste

The database has to hold all that data in memory while it processes your query. If you pull 50 columns when you need 1, شما are wasting 98% of your available RAM.

3. Disabling Index Optimization

As we saw yesterday, an **Index-Only Scan** is only possible if you *don't* ask for columns that aren't in the index. `SELECT *` forces the database to visit the disk for every single row.

The Rule

Never use `SELECT *` in production code. Always list your columns explicitly. Your future self (and your database) will thank you.

Your Task for Today

Find one `SELECT *` in your app and replace it with the specific 2-3 columns you actually need.

*Day 94: Normalization vs Denormalization (The Performance Trade-off).*

Ready to put your knowledge into practice?

Join SQL Mastery and learn through interactive exercises.