Why it matters
Most slow or wrong queries fail in familiar ways. A function around a column in WHERE stops the index being used. NOT IN against a subquery quietly returns nothing when the subquery contains a NULL. = NULL is never true. An UPDATE without WHERE changes every row. None of these are syntax errors, so the database runs them without complaint.
This linter reads the structure of your SQL, statement by statement and subquery by subquery, and flags 23 of these patterns with the line, the reason and the usual fix. It doesn't need your schema, so it works with any database. The rules were checked against an independent implementation on sqlglot's parse tree.
How to use it
- Paste one or more SQL statements.
- Read the findings, worst first in the summary.
- Switch off rules that don't apply to you.
- Fix and paste again.
FAQ
What does non-sargable mean?
A condition the database can't answer with an index seek, usually because the column is inside a function or a calculation.
Why is NOT IN with a subquery risky?
If the subquery returns any NULL, x NOT IN (…) is never true, so the query returns no rows. NOT EXISTS doesn't have that problem.
Is SELECT * always bad?
It's fine for quick exploration. In application code it fetches columns you don't use and breaks when the table changes.
Does it know my indexes?
No. It works from the SQL alone. Use EXPLAIN to see what the database actually does.
