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:

name
Wireless Mouse
Mechanical Keyboard
USB-C Hub
SQL for Beginners
Data Science Handbook
Coffee Maker Pro
Yoga Mat Premium
Running Shoes X1
Bluetooth Speaker
Stainless Water Bottle

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

Read It Like English

SQL was intentionally designed to be readable. Try saying the query out loud: "Select the name from the products table." This natural flow is why SQL has remained beginner-friendly for over 50 years.

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:

email
alice@email.com
bob@email.com
carol@email.com
david@email.com
eva@email.com
frank@email.com

Another example, retrieving just the prices:

SELECT price
FROM products;

Output:

price
29.99
89.99
45.00
34.99
42.50
129.99
38.00
110.00
65.00
24.99

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:

name	price
Wireless Mouse	29.99
Mechanical Keyboard	89.99
USB-C Hub	45.00
SQL for Beginners	34.99
Data Science Handbook	42.50
Coffee Maker Pro	129.99
Yoga Mat Premium	38.00
Running Shoes X1	110.00
Bluetooth Speaker	65.00
Stainless Water Bottle	24.99

You can add as many columns as the table contains:

SELECT name, price, stock_quantity, is_available
FROM products;

Output:

name	price	stock_quantity	is_available
Wireless Mouse	29.99	150	true
Mechanical Keyboard	89.99	75	true
USB-C Hub	45.00	200	true
SQL for Beginners	34.99	50	true
Data Science Handbook	42.50	30	true
Coffee Maker Pro	129.99	25	true
Yoga Mat Premium	38.00	100	true
Running Shoes X1	110.00	60	true
Bluetooth Speaker	65.00	0	false
Stainless Water Bottle	24.99	180	true

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:

price	name
29.99	Wireless Mouse
89.99	Mechanical Keyboard
45.00	USB-C Hub
34.99	SQL for Beginners
42.50	Data Science Handbook
129.99	Coffee Maker Pro
38.00	Yoga Mat Premium
110.00	Running Shoes X1
65.00	Bluetooth Speaker
24.99	Stainless Water Bottle

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

Output:

name	price
Wireless Mouse	29.99
Mechanical Keyboard	89.99
USB-C Hub	45.00
SQL for Beginners	34.99
Data Science Handbook	42.50
Coffee Maker Pro	129.99
Yoga Mat Premium	38.00
Running Shoes X1	110.00
Bluetooth Speaker	65.00
Stainless Water Bottle	24.99

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

Common Mistake: Missing Comma Between Columns

Forgetting a comma between column names is one of the most frequent beginner errors, and it produces confusing results instead of a clear error message.

-- Wrong: No comma between 'name' and 'price'
SELECT name price
FROM products;

The database does not throw an error here. Instead, it interprets price as an alias for the name column. You get a single column of product names, but labeled as "price":

Unexpected output:

price
Wireless Mouse
Mechanical Keyboard
USB-C Hub
SQL for Beginners
Data Science Handbook
Coffee Maker Pro
Yoga Mat Premium
Running Shoes X1
Bluetooth Speaker
Stainless Water Bottle

This is misleading and hard to debug if you do not know what happened.

-- Correct: Comma separates the two columns
SELECT name, price
FROM products;

Correct output:

name	price
Wireless Mouse	29.99
Mechanical Keyboard	89.99
USB-C Hub	45.00
SQL for Beginners	34.99
Data Science Handbook	42.50
Coffee Maker Pro	129.99
Yoga Mat Premium	38.00
Running Shoes X1	110.00
Bluetooth Speaker	65.00
Stainless Water Bottle	24.99

Always double-check that each column is separated by a comma. The only column that should not have a comma after it is the last one before FROM.

SELECT * (Selecting All Columns)

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

SELECT *
FROM customers;

Output:

id	first_name	last_name	email	city	signup_date
1	Alice	Johnson	alice@email.com	New York	2023-01-15
2	Bob	Martinez	bob@email.com	Los Angeles	2023-03-22
3	Carol	Singh	carol@email.com	Chicago	2023-06-10
4	David	Chen	david@email.com	New York	2023-08-05
5	Eva	Brown	eva@email.com	Seattle	2024-01-18
6	Frank	Wilson	frank@email.com	Chicago	2024-02-28

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;

The Simple Rule

Use SELECT * for exploration and debugging. Use explicit column names for application code, APIs, reports, views, and anything that will be maintained over time.

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;

Best Practice

Always terminate your SQL statements with a semicolon. It costs nothing, prevents errors in multi-statement scripts, and is universally expected in professional environments.

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;

Data Values Can Be Case-Sensitive

While SQL keywords are case-insensitive, the data inside your tables might not be. This depends on your database system and its collation settings.

-- PostgreSQL (case-sensitive string comparison by default)
SELECT * FROM customers WHERE city = 'new york';
-- Returns: NO ROWS (because the stored value is 'New York')

SELECT * FROM customers WHERE city = 'New York';
-- Returns: Alice Johnson, David Chen

-- MySQL (case-insensitive string comparison by default)
SELECT * FROM customers WHERE city = 'new york';
-- Returns: Alice Johnson, David Chen (matches regardless of case)

To write queries that behave consistently across databases, use LOWER() or UPPER() to normalize both sides of a comparison:

-- Consistent behavior in any database
SELECT * FROM customers
WHERE LOWER(city) = 'new york';

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.

When to Use Comments

• Do comment complex business logic that is not obvious from the SQL itself
• Do comment workarounds or non-obvious decisions ("Using LEFT JOIN here because some products have no category")
• Do not comment obvious code (-- Select the name from products adds no value to SELECT name FROM products)
• Do use comments to temporarily disable code during debugging

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:

name	price
Wireless Mouse	29.99
Mechanical Keyboard	89.99
USB-C Hub	45.00
SQL for Beginners	34.99
Data Science Handbook	42.50
Coffee Maker Pro	129.99
Yoga Mat Premium	38.00
Running Shoes X1	110.00
Bluetooth Speaker	65.00
Stainless Water Bottle	24.99

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:

first_name	last_name	city
Alice	Johnson	New York
Bob	Martinez	Los Angeles
Carol	Singh	Chicago
David	Chen	New York
Eva	Brown	Seattle
Frank	Wilson	Chicago

Exercise 3: Explore the Orders Table

Use SELECT * to view everything in the orders table.

SELECT *
FROM orders;

Expected output:

id	customer_id	order_date	total_amount	status
1	1	2024-01-10	119.98	completed
2	2	2024-01-15	89.99	completed
3	1	2024-02-20	77.49	completed
4	3	2024-03-05	129.99	shipped
5	4	2024-03-12	155.00	shipped
6	5	2024-03-20	34.99	pending
7	2	2024-04-01	63.00	pending
8	6	2024-04-10	199.98	pending

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:

description	name
Gadgets, devices, and accessories	Electronics
Physical and digital books	Books
Items for home and kitchen use	Home & Kitchen
Sports equipment and accessories	Sports

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:

order_id	product_id	quantity	unit_price
1	1	2	29.99
1	3	1	45.00
2	2	1	89.99
3	4	1	34.99
3	10	1	24.99
4	6	1	129.99
5	8	1	110.00
5	3	1	45.00
6	4	1	34.99
7	7	1	38.00
7	10	1	24.99
8	2	1	89.99
8	8	1	110.00

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;

Debugging Strategy

When an error occurs, read the error message carefully. Most databases tell you the exact position where the problem was detected. Look at the few words immediately before that position. The fix is usually obvious once you know where to look.

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.