This document discusses various techniques for optimizing MySQL queries and databases, including: - Using the query cache can speed up repeating queries with the same syntax. - Choosing optimal variable types like integers over strings for size and performance. - Indexing the right columns and testing indexes regularly as tables change. - Using EXPLAIN to check query performance and identify optimization opportunities. - Profiling queries with other tools to see where time is spent. - Testing changes thoroughly before deploying optimizations.

1. Date: August 30 2013
By: Patrick Demers

2. Query Process

3. Query Cache
•
Add some overhead to every query
•
Will invalidate any cache referencing a table
that changed
•
Cannot cache query using :

4. Query Cache
•
Current Setting [ON]
must specify SQL_NO_CACHE to skip cache
•
Will speed up repeating query with the SAME
SYNTAX.
•
Compact with
FLUSH NO_WRITE_TO_BINLOG QUERY CACHE

5. Example

6. Variable Type
•
Smaller is usually better
●
less space on disk / memory and CPU cache. Fewer
CPU cycles to process
•
Simple is good
●
Use Integer instead of string (collation / char. set)
•
Avoid Null Column
●
Harder to optimize
●
Use More Space , require special processing.

7. Variable Type
•
Current Table size 12gig
•
Test Table
●
Initial : 312meg
●
After Type change : 297meg (+-
5%)

8. Variable Type
•
Size of a Varchar is 65535
•
Why use Text then
●
Stored separately
●
Allow innodb to store more row in a block
●
Use text if not retrieved most of the time
●
Will require an On Disk Temporary table (group by / order
by)
●
Use varchar for columns retrieved in most query

9. Index
•
B-Tree Index

10. Index
•
MySQL will let you index the same column
multiple times
•
Optimizer will check every index available
•
Size of the index depends on Variable Type
•
Indexing a null column requires more
processing

11. Index
•
Optimize InnoDB Table when there's a lot of
Insert / Delete.
•
Don’t create index only thinking of your
'current query'
•
Test your query often. Adding record in a table
might change an index performance.
•
InnoDB will lock every row it thinks he needs.
No Index will lock the table.

12. Index
•
Mysql can use part of an index as long as it's
left to right
•
Using a range in a where might prevent the
index to be used fully .
●
where o.date >= '2013-08-01' AND o.date <= '2013-08-30'
•
String can be indexed partially (ex: 10 char on
a 25 char field)

13. EXPLAIN
•
Useful to check a query performance
•
Give you Info on what you should change on
your query
•

14. Explain Cheat Sheet part 1
http://www.pythian.com/blog/wp-content/uploads/explain-diagram1.pdf

15. Explain Cheat Sheet part 2

16. Explain Cheat Sheet part 3

17. Profile and Session Status
•
Useful to find where MySQL Spend time
•
Show you the real work MySQL is doing , more
precise than EXPLAIN

18. Example

19. Other
•
Information_Schema.Columns
●
Useful to search all columns in all databases
●
Sql injection will try to fetch data from there most of the
time.
•
Limit
●
Try not to use big offset. Use a combination of where and
limit when possible
•
Try not to use sub-query
●
The result of a sub-query is copied to a temp. table with
no index, most of the time it should be avoided.

20. Other
•
See the optimized Query
●
EXPLAIN EXTENDED
●
SHOW WARNINGS
•
Query are not always the problem
•
Test your Doctrine query

21. Reminder
•
Before Optimizing everything, test what your
doing
•
If you change a Column Type, make sure it will
never get over that value. (skin_id example)
•
(Paysite) If you change a column type for a
client, change it everywhere to stay constant
•
Use new Relic Slow Query Report.
•
Stay Up to date with new feature.

22. Resource
•
MySQL Performance Blog
•
MySQL Blog
•
Percona Webinar
•
Percona Youtube channel
•
Pythian Varchar vs Text
•
MySQL Group By Optimization
•
MySQL Order By Optimization
•
High Performance MySQL [book]
•
Relational Database Index Design and the Optimizers [book]

23. Thank You !
Comment , Suggestion and Critics
are
Welcome :)