Go to articles list RSS

5 Tips to
Optimize Your
SQL Queries
by
Adrian Wich
Technical Writer at
Vertabelo
Posted: May 5, 2015

index performance queries

query-optimizer SQL

The SQL Language seems easy to learn the

commands follow a simple syntax and dont
describe the speci c algorithms used to
retrieve data. The simplicity might, however,
be deceptive. Not all the database functions
operate with the same ef ciency. Two very
similar queries can vary signi cantly in
terms of the computation time. This article
presents some of the best practices that can
greatly boost your SQL queries.

1. Learn How to Create Indexes

Properly

Learning how to index properly is the best thing

you can do to improve the performance of your
SQL queries. Indexes allow for quicker access to
the database in typical situations. Database
novices often nd indexes mysterious or dif cult.
They either index nothing or they try to index
everything. Of course, neither of these
approaches is right. With no indexes at all, your
queries are likely to be slow. If you index
everything, your updates and insert triggers will
be inef cient.

If youre not sure that you know enough about

indexes, take @MarkusWinands three minute-
test. Markus website Use the Index, Luke is the
best starting point to learn about indexes. He also
published an excellent book on the subject.

2. Only Retrieve the Data You

Really Need

A common way of retrieving the desired columns

is to use the * symbol even though not all the
columns are really needed:

SELECT*FROMusersWHEREage>20;

If the table is small, retrieving additional columns

wont make much of a difference. For larger data
sets, however, specifying the columns might save
a lot of computation time:

SELECTid,last_name,sex,ageFROM

Keep in mind, however, that many popular ORM

will not let you to create a query which selects
only a subset of table columns.

Similarly, if you only need a limited number of

rows you should use the LIMIT clause (or your
databases equivalent). Take a look at the
following code:

SELECTname,priceFROMproducts;

For instance, if you only want to display the rst

10 records out of 50,000 on your website, it is
advisable to inform the database about it. This
way, the database will stop the search after
nding 10 rows rather than scan the whole table:

SELECTname,priceFROMproductsLIMIT10;

The LIMIT statement is available in MySQL

and Postgresql, but other databases have ways to
achieve a similar effect.

These above examples illustrate the general idea

you should always think whether you need all
the rows returned by an SQL statement. If you
dont, there is always some room for
improvement.

3. Avoid Functions on the Left

Hand-Side of the Operator

Functions are a handy way to provide complex

tasks and they can be used both in the SELECT
clause and in the WHERE clause. Nevertheless,
their application in WHERE clauses may result in
major performance issues. Take a look at the
following example:

SELECTnicknameFROMusersWHEREDATEDIFF(

Even if there is an index on the appointment_date

column in the table users, the query will still need
to perform a full table scan. This is because we use
the DATEDIFF function on the column
appointment_date. The output of the function is
evaluated at run time, so the server has to visit all
the rows in the table to retrieve the necessary
data. To enhance performance, the following
change can be made:

SELECTnicknameFROMusersWHEREappointment_date>

This time, we arent using any functions in the

WHERE clause, so the system can utilize an
index to seek the data more ef ciently.

4. Consider Getting Rid of

Correlated Subqueries

A correlated subquery is a subquery which

depends on the outer query. It uses the data
obtained from the outer query in its WHERE
clause. Suppose you want to list all users who
have made a donation. You could retrieve the data
with the following code:

SELECTuser_id,last_nameFROMusers

In the above case, the subquery runs once for

each row of the main query, thus causing possible
inef ciency. Instead, we can apply a join:

users.user_idFROMusersINNERJOINdonationuser

If there are millions of users in the database, the

statement with the correlated subquery will most
likely be less ef cient than the INNERJOIN
because it needs to run millions of times. But if
you were to look for donations made by a single
user, the correlated subquery might not be a bad
idea. As a rule of thumb, if you look for many or
most of the rows, try to avoid using correlated
subqueries. Keep in mind, however, that using
correlated subqueries might be inevitable in some
cases.

5. Avoid Wildcard Characters at

the Beginning of a LIKE Pattern

Whenever possible, avoid using the LIKE

pattern in the following way:

SELECT*FROMusersWHEREnameLIKE

The use of the % wildcard at the beginning of

the LIKE pattern will prevent the database
from using a suitable index if such exists. Since the
system doesnt know what the beginning of the
name column is, it will have to perform a full table
scan anyway. In many cases, this may slow the
query execution. If the query can be rewritten in
the following way:

SELECT*FROusersWHEREnameLIKE'bar%'

then the performance may be enhanced. You

should always consider whether a wildcard
character at the beginning is really essential.

Bonus Tip Read the Execution

Plan

The performance of your SQL queries depends on

multiple factors, including your database model,
the indexes available and the kind of information
you wish to retrieve. The best way to keep track
of whats happening with your queries is to
analyse the execution plan produced by the
optimizer. You can use it to experiment and nd
the best solution for your statements. If you use
PostgreSQL, the article about execution plans on
our blog may be of interest to you.

Follow@vertabelo

Like Tweet Tweet

Subscribe to our newsletter

If you nd this article useful, joinour weekly

newsletter to be noti ed about the latest posts.

Your email address:

Subscribe

Related articles:

SQL Performance Explained the must-

read book

Online tools for trying out SQL design

and queries

SQL Server: Query Plan Executions and

Features

Understanding Execution Plans in

PostgreSQL

You may also like: