MySQL SELECT Queries: Syntax and Examples

What SELECT does

SELECT retrieves data from one or more sources without changing stored rows. A query chooses output expressions, names the source with FROM, and can further filter, group, sort, or limit its results. SQL is declarative: you describe which data should be returned, while the MySQL optimizer selects an execution strategy. Understanding the clauses makes queries easier to read, troubleshoot, and improve.

Start by selecting only the columns the caller needs. SELECT * is convenient when exploring a table, but it can return unnecessary data, create fragile application mappings, and make later schema changes affect consumers unexpectedly. Explicit column names document the result shape and make it easier to review whether sensitive columns are being exposed. In joined queries, qualify a column with its table name or alias when more than one source contains that column.

SELECT order_id, customer_id, total
FROM orders;

Expressions, aliases, and computed results

A SELECT list can contain expressions as well as columns. An alias gives an expression or column a readable output name. Aliases are useful to downstream code and reports, but choose stable names and avoid relying on an alias in a clause where MySQL does not permit it. The SELECT list can also include literals or functions. A query without a table source can calculate a value, which is useful for checking the server or evaluating an expression.

SELECT product_id,
       price,
       price * 1.10 AS price_with_tax
FROM products;

This computes a displayed value; it does not update the stored price. In a real pricing system, tax rules often depend on jurisdiction, product category, and rounding policy, so a simple multiplier is only an illustration. Keep derived expressions consistent with domain rules and choose exact decimal arithmetic when appropriate. See MySQL data types and built-in functions.

Combining tables and organizing clauses

Queries can read related information from multiple tables. Use an explicit join and a clear join condition rather than placing unrelated tables in FROM without a relationship, which can create a Cartesian product and multiply rows. Aliases shorten qualified names and make complex statements easier to follow. Before using a join, understand the relationship cardinality: joining one customer to many orders returns multiple rows for that customer.

SELECT o.order_id,
       c.email AS customer_email,
       o.total
FROM orders AS o
JOIN customers AS c
  ON c.customer_id = o.customer_id;

MySQL has a logical processing order that differs from the written order of clauses. FROM and joins establish the row source; WHERE filters rows; grouping and HAVING operate on groups; SELECT expressions are produced; ORDER BY arranges the result; and LIMIT restricts returned rows. This helps explain why an alias from SELECT is not available in WHERE and why a filter on an aggregate belongs in HAVING rather than WHERE.

Duplicates, ordering, and result size

A query normally returns duplicate rows if the source data and joins produce them. DISTINCT removes duplicate result rows, but it may require extra work and can hide a join or modeling mistake. Use it when unique output is actually the requirement, not as an automatic repair for unexpected multiplicity. For summaries, use aggregate functions and GROUP BY; for row-level results, joins and window functions may be more appropriate. Learn about MySQL joins and aggregate functions.

Result order is not guaranteed unless the statement has ORDER BY. When users need stable pages, include a unique tie-breaker in the ordering, such as an identifier after a timestamp. LIMIT caps the number of rows returned, but large OFFSET values may still require MySQL to scan and skip preceding rows. For deep sequential navigation, keyset pagination can be more efficient. More detail is available in WHERE, ORDER BY, and LIMIT and pagination strategies.

Readable and secure query habits

Format multi-line queries with one selected expression per line, consistent aliases, and explicit join conditions. This makes changes safer in reviews and helps isolate errors. Use a bounded result set when exploring large tables and avoid sending unnecessary columns across the network. For user-controlled filters in application code, bind values with a prepared statement. Do not concatenate input into SQL, and do not assume that hiding a field in the user interface prevents it from being retrieved.

SELECT queries can still have operational costs even though they do not modify rows. A broad scan can consume CPU and disk bandwidth, a poorly bounded query can allocate large application memory, and a query may wait behind locks depending on the operation and isolation behavior. Use EXPLAIN to inspect plans, measure representative data, and add indexes only when workload evidence supports them. Avoid using a long-running report query on a busy transactional server without considering its impact.

Build queries from a clear question

Before writing SQL, specify the rows needed, the columns to return, the relationships involved, and whether ordering or uniqueness matters. Then write the simplest query that answers that question and test edge cases such as duplicate relationships and NULL values. This habit produces queries that are easier to maintain than starting with SELECT star and adding clauses until the output seems plausible. Continue with filtering and sorting, joins, and query plans.