why would you use WHERE 1=0 statement in SQL?

This may be also used to extract the table schema from a table without extracting any data inside that table. As Andrea Colleoni said those will be the other benefits of using this.

As an answer - but also as further clarification to what @AndreaColleoni already mentioned:

manage many OR conditions in dynamic queries (e.g WHERE 1=0 OR <condition>)

Purpose as an on/off switch

I am using this as a switch (on/off) statement for portions of my Query.

If I were to use

WHERE 1=1
  AND (0=? OR first_name = ?) 
  AND (0=? OR last_name = ?)

Then I can use the first bind variable (?) to turn on or off the first_name search criterium. , and the third bind variable (?) to turn on or off the last_name criterium.

I have also added a literal 1=1 just for esthetics so the text of the query aligns nicely.

For just those two criteria, it does not appear that helpful, as one might thing it is just easier to do the same by dynamically building your WHERE condition by either putting only first_name or last_name, or both, or none. So your code will have to dynamically build 4 versions of the same query. Imagine what would happen if you have 10 different criteria to consider, then how many combinations of the same query will you have to manage then?

Compile Time Optimization

I also might add that adding in the 0=? as a bind variable switch will not work very well if all your criteria are indexed. The run time optimizer that will select appropriate indexes and execution plans, might just not see the cost benefit of using the index in those slightly more complex predicates. Hence I usally advice, to inject the 0 / 1 explicitly into your query (string concatenating it in in your sql, or doing some search/replace). Doing so will give the compiler the chance to optimize out redundant statements, and give the Runtime Executer a much simpler query to look at.

(0=1 OR cond = ?) --> (cond = ?)
(0=0 OR cond = ?) --> Always True (ignore predicate)

In the second statement above the compiler knows that it never has to even consider the second part of the condition (cond = ?), and it will simply remove the entire predicate. If it were a bind variable, the compiler could never have accomplished this.

Because you are simply, and forcedly, injecting a 0/1, there is zero chance of SQL injections.

In my SQL's, as one approach, I typically place my sql injection points as ${literal_name}, and I then simply search/replace using a regex any ${...} occurrence with the appropriate literal, before I even let the compiler have a stab at it. This basically leads to a query stored as follows:

WHERE 1=1
  AND (0=${cond1_enabled} OR cond1 = ?)
  AND (0=${cond2_enabled} OR cond2 = ?)

Looks good, easily understood, the compiler handles it well, and the Runtime Cost Based Optimizer understands it better and will have a higher likelihood of selecting the right index.

I take special care in what I inject. Prime way for passing variables is and remains bind variables for all the obvious reasons.

A usecase I can think of: you have a filter form where you don't want to have any search results. If you specify some filter, they get added to the where clause.

Or it's usually used if you have to create a sql query by hand. E.g. you don't want to check whether the where clause is empty or not..and you can just add stuff like this:

where := "WHERE 0=1"

if X then where := where + " OR ... "
if Y then where := where + " OR ... "

(if you connect the clauses with OR you need 0=1, if you have AND you have 1=1)

A query like this can be used to ping the database. The clause:

WHERE 1=0

Ensures that non data is sent back, so no CPU charge, no Network traffic or other resource consumption.

A query like that can test for:

• server availability
• CUST_ATTR49 table existence
• ID column existence
• Keeping a connection alive
• Cause a trigger to fire without changing any rows (with the where clause, but not in a select query)
• manage many OR conditions in dynamic queries (e.g WHERE 1=0 OR <condition>)