LearnContact
Lesson 2216 min read

SELECT Statement

Learn how to retrieve data from a MySQL table using the SELECT statement, and why choosing specific columns beats grabbing everything.

Introduction

Every SQL query that reads data starts the same way: with the SELECT statement. It is the single most-used command in all of SQL, and mastering it is the foundation for everything else in this course.

In this lesson, you will learn the basic syntax of SELECT, how to pick specific columns instead of grabbing an entire table, and why that choice matters more than it might first appear.

What You Will Learn
  • The basic syntax of the SELECT statement.
  • How to select one or more specific columns.
  • How SELECT * retrieves every column.
  • Why selecting only the columns you need is better practice.

Basic SELECT Syntax

At its simplest, a SELECT statement names the columns you want and the table to read them from.

SELECT column1, column2
FROM table_name;

The semicolon at the end marks where the statement finishes. MySQL keywords like SELECT and FROM are not case-sensitive, but it is conventional to write them in uppercase to make queries easier to read.

Our Example Table

Throughout this lesson (and the next few), we will query a students table. Assume it already exists and contains the following rows.

idnameagegrademarks
1Alex16A92
2Sam17B74
3Priya16A88
4Jordan18C61
5Maya17B79

Selecting Specific Columns

To retrieve only certain columns, list their names after SELECT, separated by commas. Only the columns you name will appear in the result.

SELECT name, grade
FROM students;
Result
+--------+-------+
| name   | grade |
+--------+-------+
| Alex   | A     |
| Sam    | B     |
| Priya  | A     |
| Jordan | C     |
| Maya   | B     |
+--------+-------+

The order of the columns in your SELECT list controls the order they appear in the result — it does not need to match the order the columns were originally defined in the table.

Selecting Everything with *

The asterisk (*) is a shortcut meaning "every column." It is convenient while exploring a table you are not yet familiar with.

SELECT *
FROM students;
Result
+----+--------+-----+-------+-------+
| id | name   | age | grade | marks |
+----+--------+-----+-------+-------+
| 1  | Alex   | 16  | A     | 92    |
| 2  | Sam    | 17  | B     | 74    |
| 3  | Priya  | 16  | A     | 88    |
| 4  | Jordan | 18  | C     | 61    |
| 5  | Maya   | 17  | B     | 79    |
+----+--------+-----+-------+-------+

Why Avoid SELECT *

SELECT * feels convenient, but in real applications it is usually considered bad practice once a query is doing real work. There are several concrete reasons why.

SELECT name, grade FROM students;

  • Only transfers the data actually needed.
  • Keeps working even if new columns are added later.
  • Makes the query self-documenting — readers see exactly what is used.
  • Lets the database optimize the read more effectively.

SELECT * FROM students;

  • Pulls extra columns across the network for nothing.
  • Can silently break application code if the table structure changes.
  • Hides which columns the query actually depends on.
  • Wastes memory and bandwidth on large tables.
When SELECT * Is Fine

Using SELECT * is perfectly reasonable for quick, one-off exploration while you are learning a table's structure in a console. The concern is about using it inside real application code or production queries.

Worked Example

Suppose an application only needs to display a student's name and their marks on a report card — nothing else. Selecting exactly those two columns is both faster and clearer than selecting everything.

report_card.sql
SELECT name, marks
FROM students;
Result
+--------+-------+
| name   | marks |
+--------+-------+
| Alex   | 92    |
| Sam    | 74    |
| Priya  | 88    |
| Jordan | 61    |
| Maya   | 79    |
+--------+-------+

If the students table later gains a new column, such as email, this query is completely unaffected — it still returns exactly name and marks, exactly as the report card expects.

Common Mistakes

Avoid These Mistakes
  • Forgetting the FROM clause, which is always required.
  • Using SELECT * inside application code that only needs a couple of columns.
  • Misspelling a column name, which causes an "unknown column" error.
  • Forgetting the comma between multiple selected column names.

Best Practices

  • Name only the columns your query actually needs.
  • Reserve SELECT * for quick, informal exploration.
  • Write SQL keywords in uppercase for readability.
  • End every statement with a semicolon.

Frequently Asked Questions

Does the order of columns in SELECT matter?

Yes — the result columns appear in the exact order you list them, regardless of how the table itself was defined.

Is SELECT * slower than naming columns?

It can be, especially on wide tables or tables with large text/blob columns, because unnecessary data is read and transferred.

Can I select the same column twice?

Yes, MySQL allows this, though it is rarely useful — it will simply appear twice in the result.

Do I need to know every column name in advance?

No — running SELECT * once during exploration is a common way to discover a table's columns before writing a more targeted query.

Key Takeaways

  • SELECT retrieves data; FROM specifies which table to read it from.
  • Naming specific columns returns only the data you ask for.
  • SELECT * returns every column and is convenient for quick exploration.
  • Selecting only needed columns is more efficient and more resilient to future table changes.

Summary

The SELECT statement is how you read data out of a MySQL table. You can select specific columns by name, or use * to select everything — but in real applications, naming exactly the columns you need is almost always the better choice.

Next, you will learn how to filter which rows are returned using the WHERE clause.

Lesson 22 Completed
  • You can write a basic SELECT statement.
  • You understand the difference between selecting specific columns and SELECT *.
  • You know why avoiding SELECT * is generally good practice.
Next Lesson →

WHERE Clause