MySQL Query Performance Tuning:

A 12–Step Program

FIND WHICH SQL EXAMINE THE Compare ‘rows examined’ and

TO TUNE EXPLAIN PLAN ‘rows affected or sent’ Use Optimizer Tracing
i. Tip: ‘rows sent’ <= 10x ‘rows examined’ (5.6.3+) to see why
optimizer is stuck on
certain plan
2
Use ‘EXPLAIN
1 Find the expensive EXTENDED’ with
operators / costly steps ‘SHOW WARNING’
i. Full table scans to see query
ii. Creation of temporary tables
transformations REVIEW FILTER
iii. File sorts
3 AND ACCESS
Know how query PREDICATES
is interpreted
GATHER TABLE (e.g. parameters)
INFORMATION Review data types
EVALUATE to avoid implicit
Get sizes and row Review table conversions
EXISTING definitions
counts (‘mysqlshow
INDEXES -–status {database}’)
4
Know when predicate is
applied (should be earlier

Review index
5 If it’s a view, get
rather than later)

definition the underlying

table definitions
REVIEW EXISTING
KEYS AND
If multi-column,
CONSTRAINTS
Know the selectivity and SARG-able (need index?)
MySQL will only use ANALYZE
cardinality of the columns
left-leading column COLUMNS IN (is there data skew?)
WHERE CLAUSE
7
Avoid
6 Sub-queries
Know what objects
Look for select * or exist (avoid duplicating
Know the selectivity / cardinality scalar functions efforts later on)
(some are less optimal) RUN THE QUERY
AND RECORD
TUNE THE BASELINE
QUERY METRICS
Gather average
execution times
Focus on most TIP What is primary
expensive
operations first 8 key definition?

9 Focus on
Foreign key constraints can
help the optimizer create
Look for Get the wait events and reducing ‘rows better execution plans
high-cost steps thread states examined’

LOOK FOR FREQUENTLY

Look at steps
ENCOUNTERED
CONSIDER PERFORMANCE INHIBITORS Code-based SQL
with largest
number of rows
ADJUSTING generators (e.g.
Out-of-date
statistics can impact INDEXES Consider adding PHP Generator
and indexing for MySQL)
performance virtual column
11
Seeks vs scans—
which is more Abuse of
expensive in
TIP 10 Consider using a
Use a loose index wildcards (*)—
this scenario? scan to prevent pulling back
Reduce the covering or tight temporary table
index scan too much data
rows examined creations or filesorts
Overuse of
RE-RUN THE subqueries
Cursors and Scalar functions
Record the time, rows QUERY row-by-row
examined, rows sent and processing
wait events, and compare
with initial baseline

12 Nested views or
views referencing
Optimizer/index
Make small other views
Repeat all steps until hints
changes
performance improves

Find and fix query performance faster with SolarWinds Database Performance Analyzer. Free 14-day trial at: www.solarwinds.com/dpa-download
© 2015 SolarWinds, Inc. All rights reserved.