When working with databases, it is important to make sure that the stored data is accurate, valid, consistent, and reliable.

Imagine an employee database where:

• Two employees have the same employee ID.
• A customer is created without a required name.
• An order references a customer who does not exist.
• A product has a negative price.
• Two users are registered with the same email address.
• An employee’s department ID does not exist in the departments table.

Problems like these can make a database unreliable.

SQL provides Constraints to prevent invalid data from being inserted or updated.

In this complete guide, you will learn what SQL constraints are, why they are important, the different types of constraints, syntax, practical examples, PRIMARY KEY, FOREIGN KEY, UNIQUE, NOT NULL, CHECK, DEFAULT, composite keys, constraints with CREATE TABLE, constraints with ALTER TABLE, common mistakes, best practices, and real-world examples.

---

What Are SQL Constraints?

SQL constraints are rules applied to columns or tables that control what data can be stored in a database.

Constraints help maintain data integrity and prevent invalid or inconsistent data.

For example:

CREATE TABLE employees (
    employee_id INT PRIMARY KEY,
    name VARCHAR(100) NOT NULL,
    email VARCHAR(150) UNIQUE,
    salary DECIMAL(10, 2) CHECK (salary >= 0)
);

This table has several constraints:

• PRIMARY KEY ensures every employee has a unique identifier.
• NOT NULL requires a name.
• UNIQUE prevents duplicate email addresses.
• CHECK prevents negative salaries.

---

Why Are SQL Constraints Important?

Without constraints, applications could accidentally insert incorrect data.

For example:

Employee ID → NULL
Email       → duplicate
Salary      → -50000
Department  → non-existing department

Constraints protect the database by enforcing rules at the database level.

They are important because they provide:

1. Data Integrity

They help ensure that data remains correct.

2. Data Consistency

They prevent conflicting or duplicate information.

3. Relationship Integrity

FOREIGN KEY constraints ensure that relationships between tables remain valid.

4. Application Safety

Even if an application contains a bug, database constraints can prevent certain invalid records from being stored.

5. Better Database Design

Constraints clearly define the rules and relationships of your data.

---

Types of SQL Constraints

The most commonly used SQL constraints are:

1. NOT NULL
2. UNIQUE
3. PRIMARY KEY
4. FOREIGN KEY
5. CHECK
6. DEFAULT

You may also encounter:

• Composite keys
• Named constraints
• Referential actions such as CASCADE
• Database-specific constraints

Let’s understand each one.

---

1. NOT NULL Constraint

The NOT NULL constraint ensures that a column cannot contain a NULL value.

For example:

CREATE TABLE employees (
    employee_id INT,
    name VARCHAR(100) NOT NULL
);

The name column must contain a value.

This is allowed:

INSERT INTO employees (employee_id, name)
VALUES (1, 'Rahul');

But this is not:

INSERT INTO employees (employee_id, name)
VALUES (2, NULL);

The database rejects the row because name is defined as NOT NULL.

---

Why Use NOT NULL?

Use NOT NULL when a value is required for the record to make sense.

Common examples include:

User name
Email
Product name
Order date
Employee ID
Course name

For example:

CREATE TABLE products (
    product_id INT PRIMARY KEY,
    product_name VARCHAR(200) NOT NULL,
    price DECIMAL(10, 2) NOT NULL
);

A product must have a name and price.

---

2. UNIQUE Constraint

The UNIQUE constraint ensures that values in a column are not duplicated.

Example:

CREATE TABLE users (
    user_id INT PRIMARY KEY,
    email VARCHAR(150) UNIQUE
);

If this record exists:

user_id = 1
email = user@example.com

another row cannot normally use the same email:

user_id = 2
email = user@example.com

The database will reject the duplicate according to the database’s uniqueness rules.

---

UNIQUE Example

INSERT INTO users (user_id, email)
VALUES (1, 'rahul@example.com');

INSERT INTO users (user_id, email)
VALUES (2, 'rahul@example.com');

The second insertion violates the UNIQUE constraint.

---

UNIQUE on Multiple Columns

A unique constraint can apply to a combination of columns.

For example:

CREATE TABLE enrollments (
    student_id INT,
    course_id INT,
    UNIQUE (student_id, course_id)
);

This means the same student cannot be enrolled in the same course more than once.

However, the same student can enroll in different courses:

student_id | course_id
-----------|----------
1          | 101
1          | 102
2          | 101

But this combination would be duplicated:

1 | 101
1 | 101

---

3. PRIMARY KEY Constraint

A PRIMARY KEY uniquely identifies every row in a table.

For example:

CREATE TABLE employees (
    employee_id INT PRIMARY KEY,
    name VARCHAR(100)
);

The employee_id must uniquely identify each employee.

A primary key generally has two important properties:

• It must be unique.
• It cannot be NULL.

---

PRIMARY KEY Example

INSERT INTO employees (employee_id, name)
VALUES (1, 'Rahul');

INSERT INTO employees (employee_id, name)
VALUES (2, 'Priya');

This is valid.

But:

INSERT INTO employees (employee_id, name)
VALUES (1, 'Amit');

is rejected because employee ID 1 already exists.

---

Primary Key vs UNIQUE

Both enforce uniqueness, but they serve different design purposes.

Feature	PRIMARY KEY	UNIQUE
Uniqueness	Yes	Yes
NULL allowed	No	Database-dependent rules; commonly allows NULL
Main identifier	Yes	Usually no
Number per table	Usually one primary key constraint	Multiple possible
Foreign key target	Commonly used	Can be referenced when the referenced key satisfies database requirements

A table normally has one primary key, although that primary key can contain multiple columns.

---

4. FOREIGN KEY Constraint

A FOREIGN KEY creates a relationship between tables.

For example, suppose you have:

departments

department_id
department_name

and:

employees

employee_id
name
department_id

The employee’s department_id can reference the department table.

CREATE TABLE departments (
    department_id INT PRIMARY KEY,
    department_name VARCHAR(100) NOT NULL
);

Then:

CREATE TABLE employees (
    employee_id INT PRIMARY KEY,
    name VARCHAR(100) NOT NULL,
    department_id INT,
    FOREIGN KEY (department_id)
        REFERENCES departments(department_id)
);

Now the database can enforce that an employee’s department exists in the departments table.

---

Why Is FOREIGN KEY Important?

Without a foreign key, you could accidentally create an employee with:

department_id = 999

even if department 999 does not exist.

This creates an invalid relationship.

A foreign key helps maintain referential integrity.

---

FOREIGN KEY Example

First insert a department:

INSERT INTO departments
(department_id, department_name)
VALUES
(1, 'IT');

Then insert an employee:

INSERT INTO employees
(employee_id, name, department_id)
VALUES
(101, 'Rahul', 1);

This works because department 1 exists.

But:

INSERT INTO employees
(employee_id, name, department_id)
VALUES
(102, 'Amit', 999);

will normally fail because department 999 does not exist.

---

FOREIGN KEY with Multiple Tables

Consider an e-commerce database:

customers
    ↓
orders
    ↓
order_items
    ↓
products

You can define relationships using foreign keys.

For example:

CREATE TABLE customers (
    customer_id INT PRIMARY KEY,
    name VARCHAR(100) NOT NULL
);

Then:

CREATE TABLE orders (
    order_id INT PRIMARY KEY,
    customer_id INT NOT NULL,
    FOREIGN KEY (customer_id)
        REFERENCES customers(customer_id)
);

Now every order must reference a valid customer.

---

5. CHECK Constraint

The CHECK constraint ensures that a value satisfies a specified condition.

For example:

CREATE TABLE employees (
    employee_id INT PRIMARY KEY,
    name VARCHAR(100),
    salary DECIMAL(10, 2)
        CHECK (salary >= 0)
);

This prevents negative salaries.

---

CHECK Example

This is valid:

INSERT INTO employees
(employee_id, name, salary)
VALUES
(1, 'Rahul', 50000);

This is invalid:

INSERT INTO employees
(employee_id, name, salary)
VALUES
(2, 'Amit', -10000);

The second record violates:

CHECK (salary >= 0)

---

CHECK with Age

For example:

CREATE TABLE users (
    user_id INT PRIMARY KEY,
    name VARCHAR(100),
    age INT CHECK (age >= 18)
);

This prevents ages below 18.

However, whether NULL is permitted depends on whether the column is also declared NOT NULL. A CHECK constraint is not automatically the same thing as NOT NULL.

---

CHECK with Multiple Conditions

You can use logical operators:

CREATE TABLE products (
    product_id INT PRIMARY KEY,
    price DECIMAL(10, 2)
        CHECK (price >= 0),
    stock INT
        CHECK (stock >= 0)
);

You can also define more complex conditions where supported:

CHECK (start_date <= end_date)

---

6. DEFAULT Constraint

A DEFAULT value is automatically used when a value is not supplied during insertion.

Example:

CREATE TABLE users (
    user_id INT PRIMARY KEY,
    name VARCHAR(100) NOT NULL,
    status VARCHAR(20) DEFAULT 'active'
);

If you insert:

INSERT INTO users (user_id, name)
VALUES (1, 'Rahul');

the database can automatically set:

status = active

---

DEFAULT Example

Another example:

CREATE TABLE products (
    product_id INT PRIMARY KEY,
    product_name VARCHAR(200) NOT NULL,
    stock INT DEFAULT 0
);

If stock is not supplied:

INSERT INTO products (product_id, product_name)
VALUES (1, 'Laptop');

the default stock becomes:

0

---

DEFAULT with Current Date

Many databases allow expressions or functions such as:

created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP

For example:

CREATE TABLE users (
    user_id INT PRIMARY KEY,
    name VARCHAR(100) NOT NULL,
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

This can automatically store the creation timestamp.

The exact syntax and behavior can vary by database system.

---

Combining Multiple Constraints

You can apply multiple constraints to the same column.

For example:

CREATE TABLE users (
    user_id INT PRIMARY KEY,
    name VARCHAR(100) NOT NULL,
    email VARCHAR(150) NOT NULL UNIQUE,
    age INT CHECK (age >= 18),
    status VARCHAR(20) DEFAULT 'active'
);

Here:

user_id → PRIMARY KEY
name → NOT NULL
email → NOT NULL + UNIQUE
age → CHECK
status → DEFAULT

This creates strong validation rules at the database level.

---

Complete SQL Constraints Example

Consider a simple e-commerce database.

Customers Table

CREATE TABLE customers (
    customer_id INT PRIMARY KEY,
    name VARCHAR(100) NOT NULL,
    email VARCHAR(150) NOT NULL UNIQUE,
    status VARCHAR(20) DEFAULT 'active'
);

Products Table

CREATE TABLE products (
    product_id INT PRIMARY KEY,
    product_name VARCHAR(200) NOT NULL,
    price DECIMAL(10, 2) NOT NULL CHECK (price >= 0),
    stock INT DEFAULT 0 CHECK (stock >= 0)
);

Orders Table

CREATE TABLE orders (
    order_id INT PRIMARY KEY,
    customer_id INT NOT NULL,
    order_date TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    FOREIGN KEY (customer_id)
        REFERENCES customers(customer_id)
);

This database now has several layers of data protection.

---

Named Constraints

You can explicitly give a constraint a name.

For example:

CREATE TABLE employees (
    employee_id INT,
    salary DECIMAL(10, 2),
    CONSTRAINT pk_employees
        PRIMARY KEY (employee_id),
    CONSTRAINT chk_salary
        CHECK (salary >= 0)
);

Named constraints are useful because they make database errors and schema maintenance easier to understand.

For example:

pk_employees
chk_salary

are much more meaningful than automatically generated constraint names.

---

Composite Primary Key

A primary key can contain multiple columns.

This is called a composite primary key.

Example:

CREATE TABLE order_items (
    order_id INT,
    product_id INT,
    quantity INT NOT NULL,
    PRIMARY KEY (order_id, product_id)
);

Here, the combination of:

order_id + product_id

must be unique.

This is useful for junction or association tables.

---

Composite Key Example

Suppose:

order_id | product_id
---------|-----------
1001     | 10
1001     | 20
1002     | 10

This is valid because each combination is unique.

But:

1001 | 10
1001 | 10

would violate the composite primary key.

---

Foreign Key with ON DELETE

Foreign keys can define what happens when a referenced row is deleted.

One common option is:

ON DELETE CASCADE

Example:

CREATE TABLE orders (
    order_id INT PRIMARY KEY,
    customer_id INT NOT NULL,
    FOREIGN KEY (customer_id)
        REFERENCES customers(customer_id)
        ON DELETE CASCADE
);

If a customer is deleted, their related orders may also be deleted automatically.

Important

CASCADE should be used carefully.

Deleting a parent record can trigger deletion of many related records.

---

ON DELETE SET NULL

Another option is:

ON DELETE SET NULL

Example:

CREATE TABLE employees (
    employee_id INT PRIMARY KEY,
    department_id INT,
    FOREIGN KEY (department_id)
        REFERENCES departments(department_id)
        ON DELETE SET NULL
);

If the referenced department is deleted, the employee’s department_id can become NULL.

The column must permit NULL for this behavior.

---

ON DELETE RESTRICT

Some databases support options such as:

ON DELETE RESTRICT

This prevents deletion of a referenced parent row while dependent records still exist.

For example, if a customer has orders, deleting that customer may be blocked.

Exact support and semantics vary by database.

---

ON UPDATE Actions

Foreign keys can also define what happens when the referenced key changes.

For example:

ON UPDATE CASCADE

This can propagate a key update to related rows.

However, primary keys are generally intended to be stable identifiers, so changing them should be approached carefully.

---

Adding Constraints with ALTER TABLE

Constraints do not always have to be defined during CREATE TABLE.

You can add them later using ALTER TABLE.

For example:

ALTER TABLE employees
ADD CONSTRAINT pk_employees
PRIMARY KEY (employee_id);

---

Adding a UNIQUE Constraint

ALTER TABLE users
ADD CONSTRAINT uq_users_email
UNIQUE (email);

Now email addresses must be unique.

---

Adding a CHECK Constraint

ALTER TABLE products
ADD CONSTRAINT chk_product_price
CHECK (price >= 0);

---

Adding a FOREIGN KEY

ALTER TABLE employees
ADD CONSTRAINT fk_employee_department
FOREIGN KEY (department_id)
REFERENCES departments(department_id);

This creates a relationship between employees and departments.

---

Adding NOT NULL

Changing a column to NOT NULL is database-specific.

For example, PostgreSQL uses:

ALTER TABLE employees
ALTER COLUMN name SET NOT NULL;

SQL Server, MySQL, Oracle, and other systems use different syntax.

Before adding NOT NULL, make sure existing rows do not contain invalid NULL values.

---

Removing Constraints

You can also remove constraints.

For example:

ALTER TABLE users
DROP CONSTRAINT uq_users_email;

The exact syntax varies by database.

Some systems use different syntax for primary keys, foreign keys, or unnamed constraints.

---

SQL Constraints and NULL

Understanding NULL is essential.

Consider:

CREATE TABLE users (
    user_id INT PRIMARY KEY,
    email VARCHAR(150) UNIQUE
);

Whether multiple NULL values are allowed in a UNIQUE column depends on the database’s treatment of NULL.

This is different from:

email VARCHAR(150) NOT NULL UNIQUE

which requires an email and prevents duplicate non-NULL values.

If every record must have a unique email address, using both:

NOT NULL
UNIQUE

usually expresses the requirement clearly.

---

SQL Constraints vs Application Validation

A common question is:

Should validation happen in the application or database?

The best approach is usually both.

For example, your application can validate:

Email format
Password rules
Required fields
User-friendly error messages

The database can enforce:

UNIQUE email
NOT NULL required fields
FOREIGN KEY relationships
CHECK business rules
PRIMARY KEY uniqueness

Application validation improves the user experience.

Database constraints protect the actual data.

---

Why Database Constraints Are Important Even with Backend Validation

Imagine your application checks:

email must be unique

Two requests arrive at almost the same time.

Both requests check the database and see:

email does not exist

Both then attempt to insert it.

Without a database-level unique constraint, duplicate records may be created.

With:

UNIQUE (email)

the database can enforce uniqueness even when requests happen concurrently.

---

SQL Constraints and Data Integrity

Constraints help maintain different forms of data integrity.

Entity Integrity

Primary keys ensure each row can be uniquely identified.

PRIMARY KEY

Referential Integrity

Foreign keys maintain valid relationships between tables.

FOREIGN KEY

Domain Integrity

CHECK, NOT NULL, and appropriate data types restrict values to valid forms.

CHECK
NOT NULL

Uniqueness Integrity

UNIQUE prevents duplicate values where uniqueness is required.

---

Common SQL Constraint Mistakes

Mistake 1: Using UNIQUE Instead of PRIMARY KEY

For the main identifier of a table, use a primary key.

For example:

CREATE TABLE employees (
    employee_id INT PRIMARY KEY
);

A unique constraint can be used for additional alternate identifiers, such as email.

---

Mistake 2: Forgetting NOT NULL

Suppose every product must have a name.

This:

product_name VARCHAR(200)

allows NULL unless another rule prevents it.

Use:

product_name VARCHAR(200) NOT NULL

when the field is required.

---

Mistake 3: Forgetting Foreign Keys

You might have:

orders.customer_id

but no foreign key.

This can allow orders to reference customers that don’t exist.

Use:

FOREIGN KEY (customer_id)
REFERENCES customers(customer_id)

when the relationship should be enforced by the database.

---

Mistake 4: Using CHECK Without Considering NULL

Consider:

age INT CHECK (age >= 18)

This does not necessarily mean the age must be provided.

If age is required, use:

age INT NOT NULL CHECK (age >= 18)

This expresses both requirements:

1. Age must exist.
2. Age must be at least 18.

---

Mistake 5: Using ON DELETE CASCADE Carelessly

Consider:

ON DELETE CASCADE

Deleting one customer could potentially delete all dependent orders and related records.

Always understand the dependency chain before using cascading deletes.

---

Mistake 6: Adding Constraints to Existing Dirty Data

Suppose your table contains:

email
----------------
rahul@example.com
NULL
NULL

and you try to add:

NOT NULL

the operation may fail because existing rows violate the constraint.

Clean or migrate existing data before adding stricter constraints.

---

Best Practices for SQL Constraints

1. Use PRIMARY KEY for Row Identity

Every important table should generally have a clearly defined primary key.

Example:

employee_id INT PRIMARY KEY

---

2. Use NOT NULL for Required Data

If a value is mandatory, explicitly enforce it.

name VARCHAR(100) NOT NULL

---

3. Use UNIQUE for Business-Level Uniqueness

Examples:

Email
Username
SKU
Registration number
Invoice number

For example:

sku VARCHAR(50) UNIQUE

---

4. Use FOREIGN KEY for Relationships

If one table references another table, consider enforcing the relationship with a foreign key.

---

5. Use CHECK for Valid Ranges

For example:

CHECK (price >= 0)

or:

CHECK (quantity >= 0)

---

6. Use DEFAULT for Sensible Initial Values

For example:

status VARCHAR(20) DEFAULT 'active'

or:

stock INT DEFAULT 0

---

7. Give Important Constraints Meaningful Names

For example:

CONSTRAINT chk_product_price
CHECK (price >= 0)

This makes schema management easier.

---

8. Avoid Duplicating Business Logic Unnecessarily

A database constraint should represent a rule that truly belongs at the data-integrity level.

Complex business workflows may belong in application services, database procedures, triggers, or other architecture depending on the system.

---

SQL Constraints Example for a Real Application

Imagine you are building an online course platform.

You may have:

Students

CREATE TABLE students (
    student_id INT PRIMARY KEY,
    name VARCHAR(100) NOT NULL,
    email VARCHAR(150) NOT NULL UNIQUE,
    status VARCHAR(20) DEFAULT 'active'
);

Courses

CREATE TABLE courses (
    course_id INT PRIMARY KEY,
    course_name VARCHAR(200) NOT NULL,
    price DECIMAL(10, 2) NOT NULL CHECK (price >= 0),
    capacity INT CHECK (capacity > 0)
);

Enrollments

CREATE TABLE enrollments (
    student_id INT,
    course_id INT,
    enrollment_date TIMESTAMP DEFAULT CURRENT_TIMESTAMP,

    PRIMARY KEY (student_id, course_id),

    FOREIGN KEY (student_id)
        REFERENCES students(student_id),

    FOREIGN KEY (course_id)
        REFERENCES courses(course_id)
);

This design uses almost every major SQL constraint:

PRIMARY KEY
NOT NULL
UNIQUE
DEFAULT
CHECK
FOREIGN KEY
Composite PRIMARY KEY

---

SQL Constraints Cheat Sheet

Constraint	Purpose	Example
NOT NULL	Prevents NULL values	name VARCHAR(100) NOT NULL
UNIQUE	Prevents duplicate values	email VARCHAR(150) UNIQUE
PRIMARY KEY	Uniquely identifies rows	id INT PRIMARY KEY
FOREIGN KEY	Maintains table relationships	FOREIGN KEY (user_id) REFERENCES users(id)
CHECK	Validates a condition	CHECK (price >= 0)
DEFAULT	Supplies a default value	status DEFAULT 'active'

---

PRIMARY KEY vs FOREIGN KEY

These two constraints are especially important when designing relational databases.

PRIMARY KEY

Identifies the row in its own table.

customer_id INT PRIMARY KEY

FOREIGN KEY

References a key in another table.

FOREIGN KEY (customer_id)
REFERENCES customers(customer_id)

Think of it this way:

customers
    │
    │ customer_id
    ↓
orders
    │
    └── customer_id → FOREIGN KEY

The customer’s ID is the primary key in customers and a foreign key in orders.

---

SQL Constraints and Database Design

Constraints are an important part of relational database design.

A good database does not simply store data.

It also defines the rules that data must follow.

For example:

User
 ├── ID → PRIMARY KEY
 ├── Email → UNIQUE + NOT NULL
 ├── Status → DEFAULT
 └── Age → CHECK

Order
 ├── ID → PRIMARY KEY
 ├── Customer → FOREIGN KEY
 └── Date → DEFAULT

This makes the database more reliable and easier to maintain.

---

Frequently Asked Questions

What are SQL constraints?

SQL constraints are rules applied to database columns or tables to restrict invalid data and maintain data integrity.

---

What are the six main SQL constraints?

The commonly taught six are:

1. NOT NULL
2. UNIQUE
3. PRIMARY KEY
4. FOREIGN KEY
5. CHECK
6. DEFAULT

---

What is a PRIMARY KEY?

A primary key uniquely identifies each row in a table and does not allow NULL.

---

What is a FOREIGN KEY?

A foreign key creates a relationship between tables and helps ensure that referenced records exist.

---

What is the difference between PRIMARY KEY and UNIQUE?

Both enforce uniqueness, but the primary key is the table’s main row identifier. A table normally has one primary key constraint, while it can have multiple unique constraints.

---

What does NOT NULL do?

NOT NULL prevents a column from storing NULL.

---

What does CHECK do?

CHECK ensures that inserted or updated values satisfy a specified condition.

Example:

CHECK (salary >= 0)

---

What does DEFAULT do?

DEFAULT provides a value when an insert does not explicitly provide one for that column.

Example:

status VARCHAR(20) DEFAULT 'active'

---

Can one column have multiple constraints?

Yes.

For example:

email VARCHAR(150) NOT NULL UNIQUE

The email must be provided and must be unique.

---

Can a table have multiple UNIQUE constraints?

Yes.

For example, a users table could have unique constraints on:

email
username
phone

depending on the application’s requirements.

---

Can a table have multiple primary keys?

A table has one primary key constraint, but that primary key can contain multiple columns.

This is called a composite primary key.

---

Are SQL constraints database-independent?

The core concepts are broadly supported across relational databases, but syntax, NULL behavior, supported features, and referential-action behavior can vary between MySQL, PostgreSQL, SQL Server, Oracle, SQLite, and other systems.

Always check the documentation for your target database.

---

Conclusion

SQL constraints are essential for building reliable and well-designed relational databases.

They prevent invalid data, enforce relationships, maintain consistency, and protect the database even when application code makes mistakes.

The most important constraints to remember are:

• PRIMARY KEY → uniquely identifies each row.
• FOREIGN KEY → maintains relationships between tables.
• NOT NULL → requires a value.
• UNIQUE → prevents duplicate values.
• CHECK → validates a condition.
• DEFAULT → provides a default value.

A typical table may combine several constraints:

CREATE TABLE users (
    user_id INT PRIMARY KEY,
    name VARCHAR(100) NOT NULL,
    email VARCHAR(150) NOT NULL UNIQUE,
    age INT CHECK (age >= 18),
    status VARCHAR(20) DEFAULT 'active'
);

Once you understand SQL constraints, you have a much stronger foundation for designing relational databases.

A useful SQL learning path is:

SELECT → WHERE → JOIN → GROUP BY → HAVING → ORDER BY → Subqueries → Functions → Constraints → INSERT → UPDATE → DELETE → CTEs → Window Functions

Understanding constraints is especially important before moving deeper into database design, relationships, normalization, transactions, indexes, and advanced SQL.