Secrets Of MySQL Optimization & Performance Tuning At OSSPAC 2009

3,914 views

Published on

Sonali Minocha from OSSCube presents on Secrets of MySQL Optimization and Performance Tuning at OSSPAC 2009

OSSCube-Leading OpenSource Evangelist Company.

To know how we can help your business grow, contact:

India: +91 995 809 0987
USA: +1 919 791 5472
WEB: www.osscube.com
Mail: sales@osscube.com

Published in: Technology
0 Comments
6 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
3,914
On SlideShare
0
From Embeds
0
Number of Embeds
117
Actions
Shares
0
Downloads
379
Comments
0
Likes
6
Embeds 0
No embeds

No notes for slide
  • NEW/UPDATED
  • UPDATED changed sort_buffer to sort_buffer_size (typo? or change to variable?) added defaults
  • UPDATED moved defaults to title line
  • UPDATED moved defaults to title line
  • Secrets Of MySQL Optimization & Performance Tuning At OSSPAC 2009

    1. 1. Secrets of Best MySQL Optimization Presented by – Sonali Minocha OSSCube
    2. 2. Who Am I?
    3. 3. Why Tune a Database?
    4. 4. Who Tunes?
    5. 5. What is Tuned?
    6. 6. How much tuning is enough?
    7. 7. Application Development (Optimizing Queries)
    8. 8. Index Optimizations
    9. 9. MySQL Cluster Tutorial, OSSPAC 09 Singapore, © OSSCube
    10. 10. EXPLAIN Typessystem The table has only one rowconst At the most one matching row, treated as a constanteq_ref One row per row from previous tablesref Several rows with matching index valueref_or_null Like ref, plus NULL valuesindex_merge Several index searches are mergedunique_subquery Same as ref for some subqueriesindex_subquery As above for non-unique indexesrange A range index scanindex The whole index is scannedALL A full table scan
    11. 11. EXPLAIN ExtraUsing index The result is created straight from the indexUsing where Not all rows are used in the resultDistinct Only a single row is read per row combinationNot exists A LEFT JOIN missing rows optimization is usedUsing filesort An extra row sorting step is doneUsing temporary A temporary table is usedRange checked The read type is optimized individually forfor each record each combination of rows from the previous tables
    12. 12. Optimizer HintsSTRAIGHT_JOIN Forces the optimizer to join the tables in the given orderSQL_BIG_RESULTS Together with GROUP BY or DISTINCT tells the server to use disk-based temp tablesSQL_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 indexFORCE INDEX Forces the optimizer to use the index (if possible)IGNORE INDEX Forces the optimizer not the use the index
    13. 13. 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
    14. 14. • The general query log can be use to analyze: – Reads vs. writes – Simple queries vs. complex queries – etc
    15. 15. Database Designing(Optimizing Schemas)
    16. 16. Normalization
    17. 17. Table Optimizations
    18. 18. 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
    19. 19. MyISAM-Specific Optimizations
    20. 20. 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
    21. 21. Monitoring Threads in MySQL
    22. 22. MEMORY-Specific Optimizations
    23. 23. Optimizing the Server
    24. 24. Performance Monitoring
    25. 25. 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
    26. 26. • 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
    27. 27. Status Variables
    28. 28. SQL/Parser ModelClient1 Client2 ClientN MySQL Server Connection Thread Pool Query Cache  InnoDB Storage Engines  MyISAM  MERGE Parser Query 101101  MEMORY  Federated  ARCHIVE Optimizer  NDBCluster
    29. 29. 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
    30. 30. • 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
    31. 31. 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
    32. 32. 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
    33. 33. • 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
    34. 34. 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
    35. 35. 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
    36. 36. 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)
    37. 37. • 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
    38. 38. 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
    39. 39. Thank you for your time and attention www.osscube.comFor more information, please feel free to drop in a line to sonali@osscube.com or visit http://www.osscube.com
    40. 40. QnA

    ×