Most SQL problems aren't about syntax. They're about habits. The same bad patterns show up in every codebase, written by developers who knew better but were in a hurry. Here are five to stop immediately.
1. Single-line queries
``sql
SELECT u.id, u.name, u.email, o.total FROM users u INNER JOIN orders o ON u.id = o.user_id WHERE u.active = 1 AND o.total > 100 ORDER BY o.created_at DESC LIMIT 50
`
This works. Nothing will break. But when you have to debug it at 2am — or when a colleague has to touch it — you'll regret every character on that line.
Fix: one clause per line, always.
<code>sql
<p>SELECT</p>
<p>u.id,</p>
<p>u.name,</p>
<p>u.email,</p>
<p>o.total</p>
<p>FROM users u</p>
<p>INNER JOIN orders o ON u.id = o.user_id</p>
<p>WHERE u.active = 1</p>
<p>AND o.total > 100</p>
<p>ORDER BY o.created_at DESC</p>
<p>LIMIT 50</p>
</code>
Same query. Completely different to work with.
2. SELECT *
<code>sql
<p>SELECT * FROM users</p>
</code>
I know. It's fast to write. But it creates invisible dependencies — your application code may break silently when someone adds or removes a column. You also fetch data you don't need, which hits performance at scale.
Always name your columns. Yes, even for quick exploratory queries in development — the habit transfers to production code.
3. Implicit joins
<code>sql
<p>-- Old style</p>
<p>SELECT u.name, o.total</p>
<p>FROM users u, orders o</p>
<p>WHERE u.id = o.user_id</p>
</code>
This is valid SQL from the 1980s. It still runs. But mixing data relationships (the u.id = o.user_id filter) with data filters (business logic in WHERE) is a recipe for accidental Cartesian products and confused reviewers.
Explicit JOIN syntax is unambiguous:
<code>sql
<p>SELECT u.name, o.total</p>
<p>FROM users u</p>
<p>INNER JOIN orders o ON u.id = o.user_id</p>
</code>
4. Magic numbers in conditions
<code>sql
<p>WHERE status = 2</p>
<p>WHERE type = 7</p>
<p>WHERE permission_level >= 4</p>
</code>
What is status 2? What is type 7? You might know today. In three months, neither you nor anyone else will.
Use comments, constants in your application layer, or at minimum leave a comment in the SQL:
<code>sql
<p>WHERE status = 2 -- 2 = active</p>
<p>WHERE type = 7 -- 7 = premium_user</p>
</code>`
Better yet, if your database supports it, use an ENUM or a lookup table.
5. No formatting before committing
Raw, unformatted SQL in migrations, stored procedures, and ORM raw queries gets committed and stays there forever. Once it's in the codebase, nobody reformats it — touching it means potentially breaking it.
The fix takes 10 seconds. Before you commit any SQL, paste it into a formatter. SnappyTools SQL Formatter handles 19 dialects (PostgreSQL, MySQL, SQL Server, SQLite, BigQuery, and more). Pick your dialect, choose your indent style, format, and copy. It runs in your browser — no setup, no signup.
Good SQL is readable SQL. These aren't academic style preferences — they directly affect how quickly bugs get caught in reviews, how fast new team members can understand the codebase, and how much time you spend debugging vs. shipping.
Pick the habit that's costing you the most time right now and fix it first.
Format SQL in seconds: SnappyTools SQL Formatter — 19 dialects, browser-based, no signup.
Originally published at https://snappytools.app/sql-formatter-beautifier/</a></em></p>