SELECT

A SQL query says what you want, not how to get it. You name the columns, you name the table, and the database works out the rest.

SELECT name, country
FROM customers;

Read it in the order the database does: FROM customers picks the table, then SELECT name, country picks the two columns to return. Every other column in the table is simply not in the answer.

Try it

Renaming a column

AS renames a column in the output. The table is untouched; only the name in the result changes.

SELECT name AS customer, country AS market
FROM customers;

Removing duplicates

SELECT DISTINCT country FROM customers returns each different country once. DISTINCT applies to the whole selected row: SELECT DISTINCT name, country removes only rows where both columns repeat.

Why not SELECT *

SELECT * returns every column. It is fine while you are exploring, and a bad habit everywhere else:

• it moves data you do not need across the network, on every row;
• it breaks quietly when somebody adds a column, because your code is now reading a shape it has never seen;
• it stops the database using an index that covers only the columns you actually wanted.

Naming the columns is two seconds of typing that says exactly what your code depends on.

Common mistakes

• Leaving out a comma. SELECT name country is not an error: the second word becomes an alias for the first, so you get one column, called country, full of names (run it below).
• Expecting AS to change the table. It renames the column in this result only. The next query sees the original name.
• Using in application code. The query keeps working when a column is added, and the code reading it quietly gets a shape it was never written for.

What interviewers ask

• What does it mean that SQL is declarative? You describe the result you want; the database chooses how to produce it, and may choose differently as the data grows.
• In what order are the clauses of a query evaluated? Logically FROM, WHERE, GROUP BY, HAVING, SELECT, ORDER BY, then LIMIT — not the order they are written in.
• Why avoid SELECT * in production code? It ships columns nobody reads, hides schema changes from the code, and can stop an index that covers the needed columns from answering the query on its own.