MySQL Performance Tuning: Top 10 Tips

OSS Cube|OSI Days 2010 1 1 MySQL Performance Tuning: Top 10 Tips Presented by :- Sonali Minocha Osscube, New Delhi

OSS Cube|OSI Days 2010 2 2 Why Tune a Database? Cost-effectiveness o A system that is tuned can minimize the need to buy additional hardware and other resources to meet the needs of the end users. o Tuning may demonstrate that the system being used is excessive for the end users and downsizing is the better option. This may result in multiple levels of savings to include maintenance. · Performance o A high-performance, well-tuned system produces faster response time and better throughput within the organization. This increases the productivity of the end users. o A well-tuned system benefits the organization’s customers, poor response time causes lot of unhappiness and loses business. · Competitive Advantage o Tuning a system for optimal performance gives the end users the ability to glean more critical information faster than the competitors thus giving the company as a whole an advantage. o Tuning the access to the data helps business analysts, who are utilizing business intelligence initiatives based on corporate data, make faster and more precise decisions.

OSS Cube|OSI Days 2010 3 3 Who Tunes? • All persons involved with the MySQL software should be concerned with performance and involved in tuning. Consider all phases of the System Development Life Cycle (SDLC) as opportunities to create and enhance an effective, well designed and efficient system. • · Application Designers • · Application Developers • · Database Administrators • · System Administrators

OSS Cube|OSI Days 2010 4 4 What is Tuned? Careful design of systems and applications is essential to the optimal performance of any database. In most cases the greatest gain in performance can be achieved through tuning the application. The most opportune time to consider performance issues is when the application is in the very early stages of the SDLC. • · Application Design • · Application Development • · Database Structures • · Hardware

OSS Cube|OSI Days 2010 5 5 When should Tuning be accomplished? • · From the beginning • · Routine tune-ups • · Response to problems/bottlenecks • · Proactive Tuning • · End-of-life • o Bottom line, performance tuning is never finished. As long as the database system is in • place, the DBA will continually be adjusting the database architecture to meet the • continual needs of the end user. • Tuning Outcome • The effect of tuning should be readily apparent to the end user. For this reason, the tuning outcome • should be to: • · Minimize or decrease the response time • · Provide high throughput scalability at comparable response times • Tuning Targets • Tuning goals can be defined in numerous ways. In many cases the goals are set by the users of the • system in order for them to perform their daily functions efficiently. • · How much data needs to be processed? • · How quickly can the information be returned to the user? • · What is the total number of users that can efficiently access the data?

OSS Cube|OSI Days 2010 6 6 How much tuning is enough? • Too Little Tuning • Too Much Tuning • Other Questions to Consider • · Is the cost of improving the database architecture or adding additional resources cost effective for the return on investment that the data is providing to the organization? • · Are changes made to database systems that are in production? • · Is the integrity of the data being compromised for speed? • There comes a point when the system is in balance, and it is better not to adjust settings to achieve infinitesimally small performance improvements. • Caution is required when making changes once a system is in production. For best results, always try to build a test environment

OSS Cube|OSI Days 2010 7 7 Stages of Tuning • Application design • Application development • Database configuration • Application maintenance and growth • Troubleshooting

OSS Cube|OSI Days 2010 8 8 Measurement Methods • Benchmarking • Profiling • Benchmarking Vs Profiling

OSS Cube|OSI Days 2010 9 9 Application Development (Optimizing Queries)

OSS Cube|OSI Days 2010 10 10 Indexes • In MySQL there are several types of indexes: – Tree Indexes • B-Trees – FULLTEXT indexes (based on words instead of whole columns) • B+Trees (InnoDB) • T-Trees (NDB) • Red-black binary trees (MEMORY) • R-Trees (MyISAM, spatial indexes) – Hash indexes (MEMORY and NDB) • The use of indexes to find rows speedes up most queries • Writes become slower with each added index

OSS Cube|OSI Days 2010 11 11 Query Execution Plan (EXPLAIN) • With EXPLAIN the query is sent all the way to the optimizer, but not to the storage engine • Instead EXPLAIN returns the query execution plan • EXPLAIN tells you: – In which order the tables are read – What types of read operations that are made – Which indexes could have been used – Which indexes are used – How the tables refer to each other – How many rows the optimizer estimates to retrieve from each table

OSS Cube|OSI Days 2010 12 12 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

OSS Cube|OSI Days 2010 13 13 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 The read type is optimized individually for each combination of rows record from the previous tables

OSS Cube|OSI Days 2010 14 14 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

OSS Cube|OSI Days 2010 15 15 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 • The general query log can be use to analyze: – Reads vs. writes – Simple queries vs. complex queries – etc

OSS Cube|OSI Days 2010 16 16 Database Designing (Optimizing Schemas)

OSS Cube|OSI Days 2010 17 17 Normalization • Normalization is a key factor in optimizing your database structure – Good normalization prevents redundant data from being stored in the same tables – By moving redundant data to their own table, this reduces storage requirements and overhead when processing queries – Transactional databases should be in the 3rd normal form • For data warehousing and reporting system a star-schema might be a better solution

OSS Cube|OSI Days 2010 18 18 Table Optimizations • Use columns that are as short as possible; – INT instead of BIGINT – VARCHAR(10) instead of VARCHAR(255) – etc. • Pay special attention to columns that are used in joins • Define columns as NOT NULL if possible • For hints on saving space, use PROCEDURE ANALYSE() • For data warehousing or reporting systems consider using summary tables for speed

OSS Cube|OSI Days 2010 19 19 Index Optimizations • An index on the whole column is not always necessary – Instead index just a prefix of a column – Prefix indexes take less space and the operations are faster • Composite indexes can be used for searches on the first column(s) in the index • Minimize the size of PRIMARY KEYs that are used as references in other tables – Using an auto_increment column can be more optimal • A FULLTEXT index is useful for – word searches in text – searches on several columns

OSS Cube|OSI Days 2010 20 20 MyISAM-Specific Optimizations • Consider which row format to use, dynamic, static or compressed – Speed vs. space • Consider splitting large tables into static and dynamic parts • Important to perform table maintenance operations regularly or after big DELETE/UPDATE operations – Especially on tables with dynamic row format • Change the row-pointer size (default 6b) for large (>256Tb) tables or smaller (< 4Gb) tables

OSS Cube|OSI Days 2010 21 21 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

OSS Cube|OSI Days 2010 22 22 MEMORY-Specific Optimizations • Use BTREE (Red-black binary trees) indexes – When key duplication is high – When you need range searches • Set a size limit for your memory tables – With --max_heap_table_size • Remove unused memory – TRUNCATE TABLE to completely remove the contents of the table – A null ALTER TABLE to free up deleted rows

OSS Cube|OSI Days 2010 23 23 Optimizing the Server

OSS Cube|OSI Days 2010 24 24 Performance Monitoring • Server performance can be tracked using native OS tools – vmstat, iostat, mpstat on Unix – performance counters on Windows • The mysqld server tracks crucial performance counters – SHOW STATUS gives you a snapshot – Can use Cricket, SNMP, custom scripts to graph over time – MySQL Administrator • Default graphs • Allows you to create your own graphs • Queries can be tracked using log files – Can collect every query submitted to the server – Slow queries can be logged easily

OSS Cube|OSI Days 2010 25 25 Monitoring Threads in MySQL • To get a snapshot of all threads in MySQL – SHOW FULL PROCESSLIST – The state column shows what’s going on for each query • Performance problems can often be detected by – Monitoring the processlist – Verifying status variables • Imminent problems can be eliminated by – Terminating runaway or unnecessary threads with KILL

OSS Cube|OSI Days 2010 26 26 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 • 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

OSS Cube|OSI Days 2010 27 27 Status Variables • MySQL collects lots of status indicators – These can be monitored with SHOW STATUS • The variables provide a way of monitoring the server activity • They also act as guides when optimizing the server • The variables can also be viewed with – mysqladmin extended-status – MySQL Administrator • Provides graphical interface for monitoring the variables • Can be very efficient for tracking the health of the server

OSS Cube|OSI Days 2010 28 28 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 • 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

OSS Cube|OSI Days 2010 29 29 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

OSS Cube|OSI Days 2010 30 30 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

OSS Cube|OSI Days 2010 31 31 InnoDB-Specific Optimization 1/2 • 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) • 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

OSS Cube|OSI Days 2010 32 32 InnoDB-Specific Optimization 2/2 • 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

OSS Cube|OSI Days 2010 33 33 Q&A

OSS Cube|OSI Days 2010 34 34 Thank you

http://www.osscube.com	176
http://staging.osscube.com	48
http://www.osscube.in	7
http://dev3qa.osscube.co.uk	3
http://dev.osscube.com	3
http://localhost	3
http://druposs.osscube.com	2
http://dev3qa.osscube.co.in	2
http://www.databasejournal.com	1
http://feeds2.feedburner.com	1
http://www.osscube.co.uk	1

MySQL Performance Tuning: Top 10 Tips

by OSSCube LLC A Global Open Source Enterprise for Open Source Solutions on Sep 28, 2010

Accessibility

Categories

Tags

Upload Details

Usage Rights

11 Embeds 247

Statistics

MySQL Performance Tuning: Top 10 Tips — Presentation Transcript