Top Banner
Secrets of Best MySQL Optimization presented by Sonali Minocha OSSCube
45

MySQL Performance Tuning - GNUnify 2010

Oct 21, 2014

Download

Technology

Presnetation on MySQL Performance Tuning Best Practices,
presented by Sonali Minocha, OSSCube
at GNUnify 2010
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Page 1: MySQL Performance Tuning - GNUnify 2010

Secrets of Best MySQL Optimization

presented by

Sonali MinochaOSSCube

Page 2: MySQL Performance Tuning - GNUnify 2010

Who Am I?

Page 3: MySQL Performance Tuning - GNUnify 2010

Why Tune a Database?

Page 4: MySQL Performance Tuning - GNUnify 2010

Who Tunes?

Page 5: MySQL Performance Tuning - GNUnify 2010

What is Tuned?

Page 6: MySQL Performance Tuning - GNUnify 2010

How much tuning is enough?

Page 7: MySQL Performance Tuning - GNUnify 2010
Page 8: MySQL Performance Tuning - GNUnify 2010
Page 9: MySQL Performance Tuning - GNUnify 2010

Application Development(Optimizing Queries)

Page 10: MySQL Performance Tuning - GNUnify 2010
Page 11: MySQL Performance Tuning - GNUnify 2010

Index Optimizations

Page 12: MySQL Performance Tuning - GNUnify 2010
Page 13: MySQL Performance Tuning - GNUnify 2010
Page 14: MySQL Performance Tuning - GNUnify 2010
Page 15: MySQL Performance Tuning - GNUnify 2010

EXPLAIN Typessystem 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

Page 16: MySQL Performance Tuning - GNUnify 2010

EXPLAIN ExtraUsing 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

Page 17: MySQL Performance Tuning - GNUnify 2010

Optimizer HintsSTRAIGHT_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

Page 18: MySQL Performance Tuning - GNUnify 2010

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

Page 19: MySQL Performance Tuning - GNUnify 2010

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

Page 20: MySQL Performance Tuning - GNUnify 2010

Database Designing(Optimizing Schemas)

Page 21: MySQL Performance Tuning - GNUnify 2010

Normalization

Page 22: MySQL Performance Tuning - GNUnify 2010

Table Optimizations

Page 23: MySQL Performance Tuning - GNUnify 2010

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

Page 24: MySQL Performance Tuning - GNUnify 2010

MyISAM-Specific Optimizations

Page 25: MySQL Performance Tuning - GNUnify 2010

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

Page 26: MySQL Performance Tuning - GNUnify 2010

Monitoring Threads in MySQL

Page 27: MySQL Performance Tuning - GNUnify 2010

MEMORY-Specific Optimizations

Page 28: MySQL Performance Tuning - GNUnify 2010

Optimizing the Server

Page 29: MySQL Performance Tuning - GNUnify 2010

Performance Monitoring

Page 30: MySQL Performance Tuning - GNUnify 2010

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

Page 31: MySQL Performance Tuning - GNUnify 2010

• 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

Page 32: MySQL Performance Tuning - GNUnify 2010

Status Variables

Page 33: MySQL Performance Tuning - GNUnify 2010

SQL/Parser Model

Client2 ClientN

Connection Thread Pool

Parser Query 101101

Client1

Optimizer

Storage Engines InnoDB MyISAM MERGE MEMORY Federated ARCHIVE NDBCluster

Query Cache

MySQL Server

Page 34: MySQL Performance Tuning - GNUnify 2010

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

Page 35: MySQL Performance Tuning - GNUnify 2010

• 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

Page 36: MySQL Performance Tuning - GNUnify 2010

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

Page 37: MySQL Performance Tuning - GNUnify 2010

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

Page 38: MySQL Performance Tuning - GNUnify 2010

• 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

Page 39: MySQL Performance Tuning - GNUnify 2010

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

Page 40: MySQL Performance Tuning - GNUnify 2010

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

Page 41: MySQL Performance Tuning - GNUnify 2010

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)

Page 42: MySQL Performance Tuning - GNUnify 2010

• 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

Page 43: MySQL Performance Tuning - GNUnify 2010

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

Page 44: MySQL Performance Tuning - GNUnify 2010

Q n A

Page 45: MySQL Performance Tuning - GNUnify 2010

Thank you for your time and attention

For more information, please feel free to drop in a line to [email protected] or visit http://www.osscube.com

www.osscube.com