Introduction

WHERE 1 = 1 is a common SQL pattern used when building a query dynamically. It evaluates to true for every row, so it does not filter anything by itself. Its real purpose is to make later AND conditions easier to append in application code without special-casing the first predicate.

What WHERE 1 = 1 Actually Does

A statement such as this:

SELECT id, name
FROM customers
WHERE 1 = 1;

returns the same rows as:

SELECT id, name
FROM customers;

The constant expression is always true, so the database optimizer can usually discard it. It is not a security feature, and it is not a performance optimization. It is mostly a query-construction convenience.

Why People Use It in Dynamic SQL

When code adds optional filters one by one, starting with WHERE 1 = 1 avoids logic like "is this the first condition or not?"

1sql = """
2SELECT id, name, status
3FROM customers
4WHERE 1 = 1
5"""
6
7params = {}
8
9if status is not None:
10    sql += " AND status = :status"
11    params["status"] = status
12
13if city is not None:
14    sql += " AND city = :city"
15    params["city"] = city
16
17if min_age is not None:
18    sql += " AND age >= :min_age"
19    params["min_age"] = min_age

Without WHERE 1 = 1, the code would need a branch to emit either WHERE ... for the first filter or AND ... for later filters. That is why the pattern survives in many older codebases and reporting systems.

It Does Not Prevent SQL Injection

Because WHERE 1 = 1 appears so often in string-built SQL, people sometimes associate it with SQL injection prevention. That is wrong. The safe part is parameter binding, not the dummy predicate.

Good pattern:

sql = "SELECT id, name FROM customers WHERE 1 = 1 AND status = :status"
params = {"status": user_status}

Unsafe pattern:

sql = f"SELECT id, name FROM customers WHERE 1 = 1 AND status = '{user_status}'"

If untrusted input is concatenated into the SQL string, injection risk remains regardless of whether 1 = 1 is present.

Modern Alternatives

In many applications, you can avoid this pattern entirely by building a list of predicates and joining them at the end.

1conditions = []
2params = {}
3
4if status is not None:
5    conditions.append("status = :status")
6    params["status"] = status
7
8if city is not None:
9    conditions.append("city = :city")
10    params["city"] = city
11
12sql = "SELECT id, name FROM customers"
13if conditions:
14    sql += " WHERE " + " AND ".join(conditions)

This is often easier to read because the final SQL string contains only real business predicates. Query builders, ORMs, and composable DSLs also make this cleaner than manual string concatenation.

Performance Considerations

In mainstream relational databases, WHERE 1 = 1 is usually optimized away. You generally should not worry about it as a runtime cost. The bigger performance questions are:

• are the real filters selective
• do useful indexes exist
• is the query shape stable enough for plan caching
• are you paginating efficiently

If a query is slow, 1 = 1 is almost never the reason.

Common Pitfalls

• Thinking WHERE 1 = 1 changes query results in a meaningful way.
• Mistaking the pattern for a SQL injection defense instead of using parameterized queries.
• Leaving string-built SQL in place when a cleaner predicate list or query builder would be easier to maintain.
• Using WHERE 1 = 1 to justify concatenating raw user input into a query.
• Debugging performance at the dummy predicate instead of at the real filters and indexes.

Summary

• 'WHERE 1 = 1 is a convenience pattern for dynamic query construction.'
• It always evaluates to true and usually does not affect performance.
• Its presence does not make a query secure.
• Parameter binding is what prevents SQL injection.
• In modern code, predicate lists or query builders are often cleaner alternatives.