10 Bad Practices to Avoid When Writing SQL Queries for Better Performance

Writing efficient SQL queries is essential for maintaining the performance and scalability of your database. However, there are common mistakes (or "bad practices") that can lead to slow queries, increased load, and database performance issues. Here are 10 bad practices to avoid when writing SQL queries:

1. Using SELECT *

While SELECT * might seem convenient, it can have significant performance drawbacks. It retrieves all columns, even if you only need a subset of the data, which leads to unnecessary data transfer and processing.

• Why it's bad: It increases network traffic and memory usage.
• What to do instead: Always specify the exact columns you need.

-- Bad
SELECT * FROM employees;

-- Good
SELECT id, name, department FROM employees;

2. Not Using Indexes Properly

Indexes are essential for speeding up query performance, but failing to use them or over-indexing can be detrimental.

• Why it's bad: Missing indexes can cause full table scans, making queries slow. Too many indexes can degrade write performance.
• What to do instead: Create indexes on columns frequently used in WHERE, JOIN, ORDER BY, and GROUP BY clauses.

-- Bad (no index on `email`)
SELECT * FROM users WHERE email = '[e-mail]';

-- Good (create an index on `email`)
CREATE INDEX idx_email ON users(email);

3. Using OR in WHERE Clauses

Using OR in WHERE clauses can prevent indexes from being used efficiently, resulting in slow query performance.

• Why it's bad: MySQL may not be able to use indexes effectively with OR, leading to full table scans.
• What to do instead: Use IN for multiple values or refactor the query.

-- Bad
SELECT * FROM employees WHERE department = 'HR' OR department = 'Engineering';

-- Good
SELECT * FROM employees WHERE department IN ('HR', 'Engineering');

4. Using DISTINCT Unnecessarily

DISTINCT forces SQL to eliminate duplicates, which adds overhead, especially on large datasets.

• Why it's bad: DISTINCT requires extra sorting or hashing, which can slow down queries.
• What to do instead: Only use DISTINCT when it’s absolutely necessary.

-- Bad
SELECT DISTINCT department FROM employees;

-- Good (only if there are duplicates)
SELECT department FROM employees;

5. Not Limiting Result Sets

Queries that return large result sets without limiting the number of rows can lead to unnecessary processing and memory usage.

• Why it's bad: It can cause high memory usage, slow performance, and overwhelming data transfer.
• What to do instead: Always use LIMIT when you only need a subset of results.

-- Bad
SELECT * FROM employees;

-- Good
SELECT * FROM employees LIMIT 100;

6. Using NULL in WHERE Clauses Without IS NULL

Using = to compare NULL values results in incorrect behavior because NULL cannot be compared using the equality operator.

• Why it's bad: The query will fail to return results when checking for NULL.
• What to do instead: Use IS NULL or IS NOT NULL.

-- Bad
SELECT * FROM employees WHERE department = NULL;

-- Good
SELECT * FROM employees WHERE department IS NULL;

7. Using Functions in WHERE Clauses

Using functions in the WHERE clause can prevent the use of indexes and slow down query performance, as the database needs to apply the function to every row.

• Why it's bad: Functions in the WHERE clause disable index usage, resulting in full table scans.
• What to do instead: Avoid using functions on indexed columns in WHERE clauses.

-- Bad
SELECT * FROM employees WHERE YEAR(hire_date) = 2020;

-- Good
SELECT * FROM employees WHERE hire_date BETWEEN '2020-01-01' AND '2020-12-31';

8. Not Using JOIN Efficiently

Performing queries with multiple JOIN operations without considering the correct order or the proper indexes can drastically degrade performance.

• Why it's bad: Incorrect JOIN ordering or missing indexes leads to inefficient execution plans and longer query times.
• What to do instead: Always use the appropriate join order, and ensure there are indexes on the columns involved in the JOIN.

-- Bad (inefficient JOIN order)
SELECT * FROM orders o
JOIN customers c ON c.customer_id = o.customer_id
JOIN products p ON p.product_id = o.product_id;

-- Good (appropriate indexing and ordering)
SELECT * FROM orders o
JOIN products p ON p.product_id = o.product_id
JOIN customers c ON c.customer_id = o.customer_id;

9. Using SELECT in Subqueries That Return Large Results

Using a subquery that returns a large result set inside a SELECT, WHERE, or HAVING clause can slow down performance because the database has to execute the subquery for every row.

• Why it's bad: Subqueries can be inefficient if they return large result sets or if the subquery is executed multiple times.
• What to do instead: Refactor the query to use JOIN or EXISTS where applicable.

-- Bad (inefficient subquery)
SELECT * FROM orders WHERE customer_id IN (SELECT customer_id FROM customers WHERE active = 1);

-- Good (use JOIN instead)
SELECT o.* FROM orders o
JOIN customers c ON o.customer_id = c.customer_id
WHERE c.active = 1;

10. Neglecting Query Optimization and Monitoring

Failing to optimize your queries or monitor their performance can result in slow queries that degrade over time.

• Why it's bad: Unoptimized queries can lead to high CPU, memory usage, and long response times.
• What to do instead: Use EXPLAIN to analyze query execution plans and adjust queries accordingly. Also, monitor your database performance regularly.

-- Use EXPLAIN to analyze query performance
EXPLAIN SELECT * FROM employees WHERE department = 'HR';

Conclusion

By avoiding these bad practices, you can significantly improve the performance and efficiency of your SQL queries. Writing optimized SQL not only improves application speed but also helps ensure that your database scales well as the amount of data grows. Always focus on writing clear, efficient, and maintainable queries, and use indexing, limiting, and proper query structure to enhance performance.