Introduction

In MySQL, != and <> do not behave the way many people expect when NULL is involved. The reason is not a MySQL bug. It is standard SQL three-valued logic. Any direct comparison with NULL produces NULL, which behaves like "unknown," not like TRUE or FALSE.

That is why conditions such as column != NULL never match rows the way people expect. The correct fix is to use IS NULL, IS NOT NULL, or an explicitly null-safe expression.

Understand Why != NULL Fails

This query looks plausible:

SELECT *
FROM employees
WHERE salary != NULL;

But it does not work the way a programmer coming from ordinary boolean logic might expect. The comparison salary != NULL does not evaluate to TRUE for non-null salaries. It evaluates to NULL, because the database treats comparisons with an unknown value as unknown.

That means the WHERE clause does not keep those rows.

The correct form is:

SELECT *
FROM employees
WHERE salary IS NOT NULL;

IS NOT NULL is not just a stylistic preference. It is the correct SQL operator for this case.

Use Explicit Null Logic in Conditions

If you want "all rows where discount is not zero, including rows where discount is present," this works:

1SELECT *
2FROM products
3WHERE discount IS NOT NULL
4  AND discount <> 0;

The important pattern is:

• test null-ness explicitly
• then apply ordinary comparison operators to non-null values

This makes the logic readable and prevents hidden NULL results from collapsing the condition unexpectedly.

That style is usually clearer than trying to outsmart SQL's null rules with clever but less readable expressions.

It is also easier to review and maintain.

That matters over time.

And across teams.

Very often.

Use Null-Safe Expressions When Needed

Sometimes you want a comparison that treats NULL as a real comparable case. MySQL provides the null-safe equality operator <=>.

SELECT *
FROM users
WHERE last_login <=> NULL;

That is equivalent to IS NULL, but it illustrates an important idea: null-safe comparisons are special because ordinary equality and inequality operators are not null-safe.

If you want the inverse idea, you still usually write it explicitly:

SELECT *
FROM users
WHERE NOT (last_login <=> NULL);

In practice, IS NULL and IS NOT NULL are usually clearer than forcing everything through <=>.

Common Pitfalls

The biggest mistake is writing column != NULL or column = NULL and expecting normal boolean behavior.

Another common issue is forgetting that complex conditions can silently become NULL when one operand is null. The query may then return fewer rows than expected without producing an obvious syntax error.

It is also easy to blame the != operator itself when the real issue is SQL null semantics. != works normally for non-null comparisons.

Finally, if application code treats empty strings, zero values, and nulls as though they were interchangeable, query logic becomes much harder to reason about. Keep those concepts separate.

Summary

• 'column != NULL does not work because comparisons with NULL evaluate to NULL, not TRUE.'
• Use IS NULL and IS NOT NULL for null checks.
• Combine explicit null checks with ordinary comparisons when needed.
• Use MySQL's null-safe equality operator <=> only when that behavior is truly what you want.
• The issue is SQL null logic, not a broken != operator.