SELECT * returns every column exposed by the table or tables in a query. In application and production SQL, that makes the result depend on the full, changing schema—even when the code needs only a few fields. Listing the required columns makes the query’s output clearer and more stable.
Why is SELECT * a bad idea in production SQL?
A wildcard is convenient, but it hides which columns a query promises to return. That can make code fragile when a schema changes, and it can make the database read and process data the consumer never uses. SQLFluff warns that wildcard output may change in column count or order when upstream columns are added or removed, potentially contributing to slow performance, missed schema changes, or broken production code (SQLFluff rule L044).
1. Schema changes can silently alter the result
Suppose an application expects a query’s first three results to be an order ID, customer ID, and total. If a column is added, removed, or reordered in the table or view, SELECT * can change what the query returns without anyone editing the SQL. MariaDB notes that application code using a wildcard assumes which columns exist and their order, making schema changes harder (MariaDB: Why is it not good practice to use SELECT *).
Explicit projection makes the expected result visible in the query and reduces accidental coupling to unrelated schema details.
The Tool Desk
Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →#1 Best Overall
2. The query may read and materialize unused data
If a consumer needs three fields from a wide table, requesting every field can force the database or warehouse to read, transfer, and materialize unnecessary values. BigQuery recommends controlling projection by querying only needed columns; its guidance also notes that LIMIT on SELECT * does not reduce the amount of table data read (BigQuery performance best practices). A row limit caps returned rows, not the columns scanned.
3. Runtime, scan costs, and spill can increase
In a warehouse, reading more columns than necessary can increase scan work and query cost. AWS recommends selecting only needed columns in Redshift to help reduce execution time, scan costs, and disk spill (Redshift query design best practices). The actual effect depends on the engine, storage layout, query, and workload; there is no single savings percentage that applies to every query.
4. Joins can make output ambiguous or brittle
A join may include same-named fields from both inputs, such as id or created_at. A wildcard leaves the output’s intended meaning less obvious and can create name conflicts for tools or consumers that expect unique names. SQLFluff also warns that adding a same-named column to one joined input can create conflicts. Naming and qualifying each selected field makes its source explicit:
SELECT customers.customer_id, orders.order_id, orders.order_date
FROM customers
JOIN orders ON orders.customer_id = customers.customer_id;5. UNIONs and fixed-shape consumers can break
UNION combines result sets by column position and requires matching column counts with compatible types. If wildcard expansion changes on one side, a previously valid union can fail or pair the wrong values. SQLFluff identifies this risk for UNION and DIFFERENCE operations (SQLFluff rule L044).
Quick wins for a faster PC:
Clear out junk files and repair common Windows errorsFree Scan →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Repair Windows errors before they cause bigger problemsFix Now →The same fixed-shape expectation exists in ETL loads, exports, and typed application mappers. Explicit column lists make it easier to see whether both sides of a union—or a downstream consumer’s expected fields—still agree.
6. A later column can reach a consumer unintentionally
If a table gains a field, a wildcard query can start returning it even though an API, export, log, or downstream job was not designed to expose it. The new field might be an internal flag, a contact detail, a token, or a large value. This is a schema-management risk, not evidence that every wildcard query causes a security incident.
Projection is not a substitute for access control. Microsoft documents that SQL Server SELECT permissions granted at schema or database scope can cover child objects, so permission design and deliberate selection of returned fields are separate safeguards (SQL Server permissions).
7. Large reads can reduce concurrency in some databases
The concurrency impact depends on the database engine and transaction behavior. Google Cloud Spanner documents that a large read such as SELECT * FROM Singers inside a read-write transaction locks the rows read until commit or abort; processing those rows for longer can reduce write throughput (Spanner transactions). This is a Spanner-specific example, not a universal rule about how every SQL database locks reads.
Recommended Free Tools
Best Value
What should you write instead?
List the fields the query’s consumer needs, and qualify them when multiple tables are involved. For example:
-- Fragile application contract
SELECT *
FROM orders
WHERE customer_id = :customer_id;
-- Stable contract
SELECT order_id, order_date, total_amount
FROM orders
WHERE customer_id = :customer_id;Review projections when changing schemas. Teams that want automated checks can enable SQLFluff’s L044 rule in their linting workflow. For warehouse queries, inspect bytes processed and materialization after narrowing the projection; Redshift guidance also recommends selecting only necessary columns to limit scan and spill work.
When is SELECT * acceptable?
A narrow, conventional exception is EXISTS. The subquery is used to test whether at least one row exists; its selected columns are not returned as the outer query’s result. For example:
SELECT customer_id
FROM customers AS c
WHERE EXISTS (
SELECT *
FROM orders AS o
WHERE o.customer_id = c.customer_id
);This use does not make wildcard output a good default for an API, report, or application query that returns columns to a consumer. In exploratory work, a wildcard can also be convenient when inspecting a table, but replace it with an explicit projection when the query becomes part of a stable workflow.
Free tools Windows power users keep installed
One-click scans. No signup required.
Is SELECT * the same as SQL injection?
No. SELECT * controls which columns a query requests; it does not by itself make the query injectable. Injection risk comes from how untrusted input is incorporated into SQL. MySQL’s security guidance recommends prepared statements rather than unsafe string-built predicates, which can let input such as OR 1=1 change a condition and return excessive rows (MySQL security against attack). Prevent injection with parameterized queries, and treat projection hygiene as a separate design concern.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
