Presnetation on MySQL Performance Tuning Best Practices, presented by Sonali Minocha, OSSCube at GNUnify 2010

1. Secrets of Best MySQL
Optimization
presented by
Sonali Minocha
OSSCube

2. Who Am I?

3. Why Tune a Database?

4. Who Tunes?

5. What is Tuned?

6. How much tuning is enough?

9. Application Development
(Optimizing Queries)

11. Index Optimizations

15. EXPLAIN Types
system
The table has only one row
const
At the most one matching row, treated as a
constant
eq_ref
One row per row from previous tables
ref
Several rows with matching index value
ref_or_null
Like ref, plus NULL values
index_merge
Several index searches are merged
unique_subquery
Same as ref for some subqueries
index_subquery
As above for non-unique indexes
range
A range index scan
index
The whole index is scanned
ALL
A full table scan

16. EXPLAIN Extra
Using index
The result is created straight from the index
Using where
Not all rows are used in the result
Distinct
Only a single row is read per row combination
Not exists
A LEFT JOIN missing rows optimization is
used
Using filesort
An extra row sorting step is done
Using temporary
A temporary table is used
Range checked
for each record
The read type is optimized individually for
each combination of rows from the previous
tables

17. Optimizer Hints
STRAIGHT_JOIN
Forces the optimizer to join the tables in the
given order
SQL_BIG_RESULTS
Together with GROUP BY or DISTINCT
tells the server to use disk-based temp
tables
SQL_BUFFER_RESULTS Tells the server to use a temp table, thus
releasing locks early (for table-locks)
USE INDEX
Hints to the optimizer to use the given
index
FORCE INDEX
Forces the optimizer to use the index (if
possible)
IGNORE INDEX
Forces the optimizer not the use the index

18. Selecting Queries to Optimize
• The slow query log
– Logs all queries that take longer than
long_query_time
– Can also log all queries that don’t use indexes
with
--log-queries-not-using-indexes
– To log slow administrative commands use
--log-slow-admin-statements
– To analyze the contents of the slow log use
mysqldumpslow

19. • The general query log can be use to analyze:
– Reads vs. writes
– Simple queries vs. complex queries
– etc

20. Database Designing
(Optimizing Schemas)

21. Normalization

22. Table Optimizations

23. Choosing Best Suited Storage Engine
• Understanding benefits and drawbacks of
each storage engine is very important while
designing application.
• Different storage engine has different index
capability ,application need should be kept
in mind while choosing storage engine

24. MyISAM-Specific Optimizations

25. InnoDB-Specific Optimizations
• InnoDB uses clustered indexes
– The length of the PRIMARY KEY is extremely
important
• The rows are always dynamic
– Using VARCHAR instead of CHAR is almost always
better
• Maintenance operations needed after
– Many UPDATE/DELETE operations
• The pages can become underfilled

26. Monitoring Threads in MySQL

27. MEMORY-Specific Optimizations

28. Optimizing the Server

29. Performance Monitoring

30. Tuning MySQL Parameters
• Some MySQL options can be changed online
• The dynamic options are either
– SESSION specific
• Changing the value will only affect the current
connection
– GLOBAL
• Changing the value will affect the whole server
– Both
• When changing the value SESSION/GLOBAL
should be specified

31. • Online changes are not persistant over a
server restart
– The configuration files have to be changed as well
• The current values of all options can be found
with
SHOW SESSION/GLOBAL VARIABLES

32. Status Variables

33. SQL/Parser Model
Client1
Client2
ClientN
MySQL Server
Connection Thread Pool
Query Cache
Parser
Query
Optimizer
Storage Engines
101101
 InnoDB
 MyISAM
 MERGE
 MEMORY
 Federated
 ARCHIVE
 NDBCluster

34. Query Cache
• Stores SELECT queries and their results
• Purpose: improve performance for
frequently requested data
• The data in the query cache is invalidated as
soon as a modification is done in the table
• Controlled with the query_cache_size
variable

35. • The Qcache_% status variables help
monitoring the cache
– The utilisation ratio: Qcache_hits vs.
Com_select
• The query cache can be emptied with
RESET QUERY CACHE

36. Some Thread Specific Options
• read_buffer_size (default 128Kb) and
read_rnd_buffer_size (default 256Kb)
– Size of cache used for table scanning
– Not equivalent to block size
• The database is not divided into blocks but directly into
records
– Increase if you do many sequential scans
• sort_buffer_size (default 2Mb)
– Size of the GROUP BY / ORDER BY cache
– If more memory is needed it will be taken from the disk
• tmp_table_size (default 32Mb)
– Limit after which temporary tables will not be MEMORYs
anymore, but MyISAM tables

37. Some Global Options
• table_cache (default 64)
– Cache for storing open table handlers
– Increase this if Opened_tables is high
• thread_cache (default 0)
– Number of threads to keep for reuse
– Increase if threads_created is high
– Not useful if the client uses connection pooling

38. • max_connections (default 100)
– The maximum allowed number of simultaneous
connections
– Very important for tuning thread specific memory
areas
– Each connection uses at least thread_stack of
memory

39. MyISAM Global Options
• key_buffer_size (default 8Mb)
– Cache for storing indices
– Increase this to get better index handling
– Miss ratio
(key_reads/key_read_requests) should
be very low, at least < 0.03 (often < 0.01 is
desirable)
• Row caching is handled by the OS

40. MyISAM Thread-Specific Options
• myisam_sort_buffer_size (default
8Mb)
– Used when sorting indexes during
REPAIR/ALTER TABLE
• myisam_repair_threads (default 1)
– Used for bulk import and repairing
– Allows for repairing indexes in multiple threads
• myisam_max_sort_file_size
– The max size of the file used while re-creating
indexes

41. InnoDB-Specific Optimization
• innodb_buffer_pool_size (default
8Mb)
– The memory buffer InnoDB uses to cache both
data and indexes
– The bigger you set this the less disk i/o is
needed
– Can be set very high (up to 80% on a dedicated
system)

42. • innodb_flush_log_at_trx_commit
(default 1)
– 0 writes and sync’s once per second (not ACID)
– 1 forces sync to disk after every commit
– 2 write to disk every commit but only sync’s about
once per second

43. InnoDB-Specific
Optimization
• innodb_log_buffer_size (default
1Mb)
– Larger values allows for larger transactions to be
logged in memory
– Sensible values range from 1M to 8M
• innodb_log_file_size (default 5Mb)
– Size of each InnoDB redo log file
– Can be set up to buffer_pool_size

44. QnA

45. Thank you for your time and attention
www.osscube.com
For more information, please feel free to drop in a line to
sonali@osscube.com or visit http://www.osscube.com