Understanding WHERE 1=1 and WHERE 1=2 in SQL Queries

In SQL, you will often see queries written using WHERE 1=1 or WHERE 1=2. At first glance, both look pointless. One is always true, the other always false.

In practice, both are deliberate patterns used for query construction and control, not filtering logic. They exist to make SQL safer, easier to manipulate, and more predictable in real-world scripts.

---

What WHERE 1=1 Does

WHERE 1=1 always evaluates to true.

On its own, it does nothing. It does not filter rows, change execution plans, or affect performance. The SQL Server optimizer removes it during compilation.

Its value comes entirely from how it is used.

---

Why DBAs Use WHERE 1=1

The primary purpose of WHERE 1=1 is to simplify query construction and modification.

It allows you to:

• Add or remove filters without rewriting the WHERE clause
• Comment conditions in and out safely
• Append conditions dynamically without worrying about leading AND or OR

This is especially useful in:

• Dynamic SQL
• Stored procedures
• Investigative or diagnostic scripts
• Code that evolves over time

Example

SELECT *
FROM dbo.orders
WHERE 1=1
    AND order_date >= '2025-01-01'
    AND status = 'Completed';

Commenting out a condition is trivial:

SELECT *
FROM dbo.orders
WHERE 1=1
    -- AND order_date >= '2025-01-01'
    AND status = 'Completed';

No syntax changes. No risk of leaving a dangling AND.

---

WHERE 1=1 in Dynamic SQL

This is where the pattern earns its keep.

DECLARE @sql NVARCHAR(MAX);
SET @sql = '
SELECT *
FROM dbo.orders
WHERE 1=1';

IF @status IS NOT NULL
    SET @sql += ' AND status = @status';

IF @start_date IS NOT NULL
    SET @sql += ' AND order_date >= @start_date';

Using WHERE 1=1 avoids conditional logic just to decide when to add a WHERE clause. Without it, dynamic SQL quickly becomes messy and error-prone.

---

Performance Impact of WHERE 1=1

None.

The optimizer evaluates it at compile time and removes it. It does not affect cardinality estimates or execution plans in any meaningful way.

If someone claims it slows queries down, they are wrong.

---

What WHERE 1=2 Does

WHERE 1=2 always evaluates to false.

The query compiles and runs, but returns no rows. That behaviour is intentional.

---

Why DBAs Use WHERE 1=2

The most common use case is working with table structure without data.

It is used to:

• Copy a table’s column definitions
• Create an empty table with the same shape
• Inspect schema without touching data
• Build staging or scratch tables
• Prototype migrations or ETL logic safely

Example

CREATE TABLE source_table (
    id INT,
    name VARCHAR(255),
    value INT
);

INSERT INTO source_table (id, name, value)
VALUES
    (1, 'Item A', 10),
    (2, 'Item B', 20);

Create a new table with the same structure, but no rows:

SELECT *
INTO target_table
FROM source_table
WHERE 1=2;

The query defines the schema, but returns nothing.

---

Why Not Use TOP 0 or LIMIT 0?

Those approaches work, but they are platform-specific.

• TOP 0 is SQL Server–specific
• LIMIT 0 is common in PostgreSQL and MySQL

WHERE 1=2 is portable, predictable, and behaves consistently across engines, which is why DBAs often prefer it in cross-platform scripts.

---

WHERE 1=1 vs WHERE 1=2

They solve different problems:

• WHERE 1=1
  Always true. Used to simplify query construction and dynamic SQL.
• WHERE 1=2
  Always false. Used to return no rows while still compiling and defining structure.

Both look odd at first. Both exist because they make real DBA work safer and easier.

---

A Related Pattern: Leading Commas

You will often see WHERE 1=1 paired with leading commas in SELECT lists:

SELECT
     Column1
-- , Column2
   , Column3
   , Column4
FROM dbo.TableName
WHERE 1 = 1;

This follows the same philosophy: make commenting and modification low-risk.

It looks strange until you have used it under pressure. Then it becomes hard to give up.

---

Final Thoughts

Neither WHERE 1=1 nor WHERE 1=2 is required, and they do not belong in every query.

Both are useful when used deliberately for dynamic SQL, investigation, or schema work.

They become a problem when they are used to paper over messy logic or unclear intent.

The patterns themselves are not wrong. Overuse usually means the surrounding SQL needs attention.