How to Use DISTINCT in SQL

Use DISTINCT when you need only unique values from one or more columns. This is perfect for removing duplicates in reports, dropdown sources, filters, and quick data audits.

What you’ll build or solve

You’ll learn how to use DISTINCT in SQL to return unique rows. You’ll also know how it behaves with multiple selected columns.

When this approach works best

This approach is the right choice when repeated values should appear only once in the result set.

Common real-world scenarios include:

• Unique countries
• One email per user
• Filter dropdown values
• Category reporting
• Data cleanup checks

This is a bad idea when duplicates are meaningful and each row should remain visible.

Prerequisites

You only need:

• A SQL table with duplicate values
• Basic SELECT knowledge

Step-by-step instructions

Step 1: Add DISTINCT right after SELECT

Place DISTINCT before the column list.

SELECT DISTINCT country
FROM users;

This returns each country only once.

It also works across multiple columns.

SELECT DISTINCT city, country
FROM offices;

In this case, the combination of both columns must be unique.

What to look for:

• DISTINCT removes duplicate result rows
• Works with one or multiple columns
• Multi-column uniqueness checks the full combination
• Great for reports and dropdown values
• Can be slower on very large datasets

Examples you can copy

Unique countries

SELECT DISTINCT country
FROM customers;

Unique status values

SELECT DISTINCT status
FROM orders;

Unique city-country pairs

SELECT DISTINCT city, country
FROM offices;

Common mistakes and how to fix them

Mistake 1: Expecting one column to stay unique in multi-column queries

What the reader might do:

SELECT DISTINCT city, country
FROM offices;

Why it breaks: city can still repeat if paired with different countries.

Corrected approach:

Select only the exact column that needs uniqueness.

SELECT DISTINCT city
FROM offices;

Mistake 2: Using DISTINCT to hide bad joins

What the reader might do:

SELECT DISTINCT users.name
FROM users
JOIN orders ON ...

Why it breaks: duplicates may actually come from an incorrect join.

Corrected approach:

Fix the join logic first.

Mistake 3: Overusing DISTINCT in large queries

What the reader might do:

SELECT DISTINCT *
FROM events;

Why it breaks: this can be expensive and may hide data quality issues.

Corrected approach:

Select only the columns that truly need uniqueness.

Troubleshooting

If duplicates still appear, check whether multiple selected columns create unique combinations.

If performance drops, reduce the selected columns.

If DISTINCT is masking join issues, inspect the join conditions.

If the result should count unique values, combine it with COUNT().

Quick recap

• Use DISTINCT after SELECT
• It removes duplicate result rows
• Multiple columns use combined uniqueness
• Great for filters and reports
• Do not use it to hide join mistakes