SQL SELECT and FROM

The SELECT statement is where every SQL journey begins. It is the command you will use more than any other, the backbone of data retrieval, and the first thing every developer learns when picking up SQL. No matter how advanced your queries eventually become, they will always start with SELECT.

This guide teaches you the SELECT and FROM clauses from the ground up. You will learn how to retrieve data from a table, how to pick specific columns, when to use SELECT * and when to avoid it, and the fundamental syntax rules that apply to every SQL statement. Each concept is paired with practical examples and outputs so you can follow along in your own SQL environment.

We will use the ShopSmart sample database throughout this guide. If you have not set it up yet, any table with a few rows of data will work perfectly for practicing these fundamentals.

How SELECT and FROM Work Together

Every SQL query that retrieves data needs two pieces of information: what you want and where to find it. The SELECT clause answers the first question, and the FROM clause answers the second.

SELECT column_name
FROM table_name;

• SELECT declares which columns (fields) you want to see in your results
• FROM declares which table contains those columns

Think of it like placing an order at a restaurant. SELECT is what you are ordering, and FROM is which menu section you are ordering from.

Here is your first real query. To see every product name stored in the products table:

SELECT name
FROM products;

Output:

You asked for one column (name) from one table (products), and the database returned exactly that. Nothing more, nothing less.

Selecting a Single Column

The simplest form of a SELECT query retrieves one column from a table. This is useful when you need a focused list of values.

SELECT email
FROM customers;

Output:

Another example, retrieving just the prices:

SELECT price
FROM products;

Output:

The database returns only the column you specified. Every other column in the table is ignored entirely.

Selecting Multiple Columns

In practice, you almost always need more than one piece of information. To select multiple columns, separate them with commas after the SELECT keyword:

SELECT name, price
FROM products;

Output:

You can add as many columns as the table contains:

SELECT name, price, stock_quantity, is_available
FROM products;

Output:

Column Order in the Output

An important detail: the columns in your result appear in the exact order you list them in the SELECT clause, regardless of how they are defined in the table.

-- Price appears before name in the output
SELECT price, name
FROM products;

Output:

-- Name appears before price in the output
SELECT name, price
FROM products;

Output:

Same data, different presentation. You control the layout of your results simply by changing the column order in your SELECT list.

SELECT * (Selecting All Columns)

The asterisk (*) is a wildcard that means "select every column in the table":

SELECT *
FROM customers;

Output:

Every column, every row, all at once. No need to type out each column name.

When SELECT * Is the Right Choice

SELECT * is genuinely useful in specific situations:

Exploring an unfamiliar table:

-- "What columns does this table have? What does the data look like?"
SELECT *
FROM order_items;

Quick debugging during development:

-- "Let me see the full row for this specific order"
SELECT *
FROM orders
WHERE id = 5;

Interactive sessions in a query tool where you are investigating data manually and do not need to optimize performance.

Why You Should Avoid SELECT * in Production

Despite its convenience, SELECT * causes real problems when used in application code, automated reports, or any SQL that will be maintained over time. Here are the specific reasons.

1. Wasted resources

If a table has 25 columns but your application only uses 3, SELECT * transfers 22 unnecessary columns across the network. Multiply this by thousands of requests per minute, and the wasted bandwidth and memory add up quickly.

-- Bad: Retrieves all 6 columns when you only need 2
SELECT *
FROM products;
-- Returns: id, name, category_id, price, stock_quantity, is_available

-- Good: Retrieves only what you actually need
SELECT name, price
FROM products;

2. Fragile application code

When your application code processes results from SELECT *, it often depends on columns being in a certain position or having certain names. If someone adds a new column to the table, renames an existing one, or changes the column order, your application can break without any changes to your own code.

-- Your code assumes the result has columns: id, name, email
SELECT *
FROM users;

-- A week later, someone adds a 'phone' column between 'name' and 'email'
-- Your code now gets: id, name, phone, email
-- The value your code expected at position 3 (email) is now phone

3. Poor readability and self-documentation

Explicit column lists tell every developer who reads the query exactly what data is being used. SELECT * tells them nothing.

-- Unclear: What data does this feature actually need?
SELECT *
FROM orders;

-- Clear: This feature needs the order ID, date, amount, and status
SELECT id, order_date, total_amount, status
FROM orders;

4. Potential exposure of sensitive data

Tables sometimes contain columns with sensitive information like password hashes, API tokens, social security numbers, or internal notes. SELECT * retrieves all of them indiscriminately.

-- Dangerous: May expose sensitive columns you did not intend to share
SELECT *
FROM users;
-- Could return: id, name, email, password_hash, ssn, internal_notes

-- Safe: Explicitly select only non-sensitive columns
SELECT id, name, email
FROM users;

SQL Syntax Rules

Every SQL statement follows a set of syntax rules. Understanding these rules prevents frustrating errors and helps you write clean, professional queries from the start.

Semicolons End Statements

A semicolon (;) marks the end of a SQL statement. It tells the database where one command finishes.

SELECT name FROM products;

When running multiple statements in sequence, semicolons are essential for separating them:

SELECT name FROM products;
SELECT email FROM customers;
SELECT id, order_date FROM orders;

Without semicolons, the database cannot tell where one query ends and the next begins, and you will get a syntax error.

Can you skip the semicolon? In many GUI tools (pgAdmin, MySQL Workbench, DB Browser for SQLite), you can run a single query without a semicolon and it will work. However, this is a bad habit to develop.

-- Works in most GUI tools but is not a good habit
SELECT name FROM products

-- Always better to include the semicolon
SELECT name FROM products;

SQL Keywords Are Case-Insensitive

SQL does not care whether you write keywords in uppercase, lowercase, or mixed case. These three queries are identical to the database:

SELECT name, price FROM products;
select name, price from products;
SeLeCt name, price FrOm products;

All three return the exact same results. However, the SQL community has a strong convention: write keywords in UPPERCASE and identifiers (table names, column names) in lowercase.

-- Recommended convention
SELECT name, price
FROM products;

This convention is not enforced by the database, but it makes your queries significantly easier to read by creating a clear visual distinction between SQL commands and your data identifiers.

-- Hard to read: Everything blends together
select name, price, stock_quantity from products where is_available = true;

-- Easy to read: Keywords stand out immediately
SELECT name, price, stock_quantity
FROM products
WHERE is_available = true;

Whitespace and Formatting

SQL treats all whitespace identically: spaces, tabs, and line breaks are interchangeable. The database only cares about the words and their order, not how they are spaced.

These queries all produce the same result:

-- Single line
SELECT name, price, stock_quantity FROM products;

-- Each clause on its own line
SELECT name, price, stock_quantity
FROM products;

-- Each column on its own line
SELECT name,
       price,
       stock_quantity
FROM products;

-- Excessive spacing (valid but unnecessary)
SELECT     name,
           price,
           stock_quantity
FROM       products;

While the database does not care, humans do. As queries grow more complex, formatting becomes critical for readability and maintainability.

Here is the standard formatting convention used by most SQL developers:

-- Short query: single line is fine
SELECT name, price FROM products;

-- Longer query: each major clause gets its own line
SELECT name,
       price,
       stock_quantity,
       is_available
FROM products
WHERE is_available = true
  AND price > 30
ORDER BY price DESC;

Compare the formatted version above with this single-line equivalent:

SELECT name, price, stock_quantity, is_available FROM products WHERE is_available = true AND price > 30 ORDER BY price DESC;

Both work. One is maintainable. The other is a headache waiting to happen.

Comments

Comments let you add explanations, notes, or temporary annotations to your SQL. The database completely ignores them during execution.

Single-line comments start with two dashes (--). Everything after -- on that line is ignored:

-- Retrieve all product names and prices
SELECT name, price
FROM products;

You can also place single-line comments at the end of a line:

SELECT name,          -- the product's display name
       price,         -- current price in USD
       is_available   -- whether it can be ordered
FROM products;

Multi-line comments are enclosed between /* and */. They can span multiple lines:

/*
  This query feeds the inventory dashboard.
  It shows products with low stock levels
  so the purchasing team knows what to reorder.
*/
SELECT name, stock_quantity
FROM products
WHERE stock_quantity < 30;

Commenting out code is a common debugging technique where you temporarily disable part of a query without deleting it:

SELECT name,
       price
       /* , stock_quantity */
       /* , is_available   */
FROM products;

This runs the query with only name and price, while keeping the other columns ready to be re-enabled by simply removing the comment markers.

Practical Exercises

Practice is the fastest way to make these concepts stick. Try each exercise in your SQL environment, then check your results against the expected output.

Exercise 1: Product Names and Prices

Retrieve the name and price of every product.

SELECT name, price
FROM products;

Expected output:

Exercise 2: Customer Names and Cities

Retrieve the first name, last name, and city for all customers.

SELECT first_name, last_name, city
FROM customers;

Expected output:

Exercise 3: Explore the Orders Table

Use SELECT * to view everything in the orders table.

SELECT *
FROM orders;

Expected output:

Exercise 4: Reversed Column Order

Display the category description and name from the categories table, with description appearing first.

SELECT description, name
FROM categories;

Expected output:

Exercise 5: Order Items Details

From the order_items table, select the order ID, product ID, quantity, and unit price.

SELECT order_id, product_id, quantity, unit_price
FROM order_items;

Expected output:

Troubleshooting Common Errors

Here are the errors you are most likely to encounter when writing SELECT queries, with clear explanations and fixes.

Unknown Column

SELECT username
FROM customers;

Error: column "username" does not exist

What happened: There is no column called username in the customers table. The actual columns might be first_name and last_name.

Fix: Check the table structure, then use the correct column name:

-- See what columns exist
SELECT * FROM customers;

-- Use the correct column name
SELECT first_name
FROM customers;

Table Does Not Exist

SELECT name
FROM product;

Error: relation "product" does not exist

What happened: The table name is misspelled. The actual table is products (plural).

Fix: Verify available tables and correct the name:

-- Check available tables (PostgreSQL)
-- \dt

-- Check available tables (MySQL)
-- SHOW TABLES;

-- Use the correct table name
SELECT name
FROM products;

Trailing Comma

SELECT name, price,
FROM products;

Error: syntax error at or near "FROM"

What happened: There is a comma after price with no column following it. The database expects another column name before FROM.

Fix: Remove the trailing comma:

SELECT name, price
FROM products;

Missing FROM Clause

SELECT name, price;

What happened: You told the database what to retrieve but not where to find it. Without FROM, the database has no idea which table you mean.

Fix: Add the FROM clause:

SELECT name, price
FROM products;

Key Takeaways

The SELECT and FROM clauses form the foundation that every SQL query is built upon. Here is what you should take away from this guide:

• SELECT specifies which columns you want in your results
• FROM specifies which table to query
• Single column: SELECT name FROM products;
• Multiple columns: SELECT name, price, stock_quantity FROM products;
• All columns: SELECT * FROM products;
• Use SELECT * for exploration and debugging only, never in production application code
• Semicolons terminate statements and are required when running multiple queries
• SQL keywords are case-insensitive, but the convention is UPPERCASE keywords with lowercase identifiers
• Whitespace does not affect execution, but proper formatting is essential for readability
• Comments (-- and /* */) help document your queries and are invaluable for debugging

Every query you will write throughout your career, whether it involves filtering, sorting, joining, grouping, or advanced analytics, starts with SELECT ... FROM. These two keywords are your permanent companions in SQL. Master them, and you have a solid foundation for everything that comes next.