The document discusses various techniques for tuning MySQL performance. It begins with an introduction and agenda, then covers top performance issues such as bad SQL queries, long running transactions, and incorrect configurations. The rest of the document provides tips for monitoring different aspects of the system and tuning various configuration options, software, and application design factors to optimize MySQL performance.

1. MYSQL PERFORMANCE TUNING
Arnaud Adant
June 21 2017
The London MySQL

2. WHO I AM
• aadant@jumptrading.com
• 3.5 years @ Oracle MySQL as support engineer
– Filed hundreds of bugs and feature requests
• InnoDB
• Optimizer
• High availability
• Performance
• Joined Jump Trading in 2015

3. AGENDA
• Introduction
• Mostly performance tuning tips
• this presentation is an update from the 50 tips
presentation done while at Oracle for MySQL
5.6
• Questions

4. TOP PERFORMANCE ISSUES
• Bad SQL queries : 90 % of the time
• Long running idle transaction
• high history_list_length
• MDL
• Replication lag
• no primary key and row based replication
• Wrong / bad configuration
• smaller buffer pool, query cache, small redo logs
• OS, hardware

5. PERFORMANCE CHECK LIST
• #1 Monitor the queries …
• tune the apps
• #2 Monitor replication
• tune replication
• #3 Monitor the status variables
• tune the config
• #4 Monitor the OS
• tune the OS
• #5 in doubt, benchmark

6. THE APP (DEFINITION)
• Everything that is not shipped with the database
• schema
• queries
• user connections
• the app data in data files
• …

7. TUNING PROCESS
replication
status
variables
mysqld
Monitor / measure
backup
Tune
the app
Config /design
config variables
benchmark
OS
OS
config variables
OS
the app
app design
data files

8. CHANGE PROCESS
• One change at a time, test on dev = prod, then deploy
Development Production
deploy
Change Test
Monitor
OK
Monitor

9. TUNING PROCESS
1. Config
• OS
• Config variables
• App design
• Benchmark
2. Monitor
• App / status variables / replication / mysqld / os
3. Tune using the change process
• App
• Config variables
• Table spaces
• OS

10. CONFIG / OS 1/2
• RAM
• CPU
• Storage
• OS
• OS limits
• Battery backed disk cache
• Memory allocator
• CPU affinity

11. CONFIG / OS 2/2
• I/O scheduler
• File system
• Mount options
• Disk configuration
• NUMA

12. RAM
• The active data should fit in the buffer pool
• MySQL connections and caches take memory
• ECC RAM recommended
• Enable huge pages for large buffer pools : large-pages
• Extra RAM for
• FS cache
• Monitoring
• RAM disk (tmpfs)
• RAM is split over NUMA nodes

13. CPU
• Fast CPU for single threaded performance
• Recent servers have 32 to 80 cores.
• Enable hyper-threading
• MySQL 5.7 scales to 64 cores
• Minimize the number of sockets !

14. CPU
http://dimitrik.free.fr/blog/archives/2016/02/mysql-performance-scalability-on-
oltp_rw-benchmark-with-mysql-57.html

15. STORAGE
• Good for IO bound loads
• HDD for sequential reads and writes
• Bus-attached SSD for random reads and writes
• NVMe : Non-Volatile Memory Express
• Big sata or other disk for log files
• Several disks ! If striping, mind the stripe size, align
• Life time for low end SSD is a concern

16. OPERATING SYSTEM
• Linux !
• pick a modern distribution
• also works well on Windows, FreeBSD, MacOS, Solaris

17. OS LIMITS (LINUX)
• Max open files per process
• ulimit –n
• limits the number of file handles (connections, open
tables, …)
• Max threads per user
• ulimit –u
• limits the number of threads (connections, event
scheduler, shutdown)

18. BATTERY BACKED DISK CACHE
• Usually faster fsyncs
• InnoDB redo logs
• binary logs
• data files
• Crash safety
• Durability (ACID)
• Applies to SSD

19. MEMORY ALLOCATOR
• jemalloc is a good malloc replacement
[mysqld_safe]
malloc-lib=/usr/lib64/libjemalloc.so.1
Default with MariaDB
• tcmalloc shipped on Linux with MySQL
[mysqld_safe]
malloc-lib=tcmalloc

20. CPU USAGE TUNING
• taskset command on Linux for core assignment
• taskset -c 1-4 `pidof mysqld`
• taskset -c 1,2,3,4 `pidof mysqld`
• niceness
[mysqld_safe]
nice=-20
also in /etc/security/limits.conf
• CPU governor
• set to performance

21. FILE SYSTEM
• ext4 best choice for speed and ease of use
• fsyncs a bit slower than ext3
• more reliable
• xfs is excellent (for experts only)
• With innodb_flush_method = O_DIRECT
• less stable recently
• ext3 is also a good choice

22. MOUNT OPTIONS
• ext4 (rw,noatime,nodiratime,nobarrier,data=ordered)*
• xfs (rw, noatime,nodiratime,nobarrier,logbufs=8,logbsize=32k)
• SSD specific
• innodb_use_trim
• innodb_page_size = 4K
• Innodb_flush_neighbors = 0
* use no barrier if you have a battery backed disk cache

23. I/O SCHEDULER
• deadline is generally the best I/O scheduler
• echo deadline > /sys/block/{DEVICE-NAME}/queue/scheduler
• the best value is HW and WL specific
• noop on high end controller (SSD, good RAID card …)
• deadline otherwise

24. DISK CONFIGURATION
• everything on one disk is killing performance
• several disks (RAID)
• or distribute the data files on different disks
• data files (ibd files)
• main InnoDB table space ibdata
• redo logs
• undo logs (if separate)
• binary logs

25. NUMA
• NUMA architecture is the norm nowadays for mysql server
• Problem : RAM is allocated to CPU sockets
• The Buffer pool should be distributed in each RAM
• Percona, MariaDB and MySQL >= 5.6 support NUMA
• The usual trick is using mysql_safe
• flush the FS cache --flush-caches
• use NUMA interleave --numa-interleave

26. NUMA
• From 10.1, 5.7, -- innodb-numa-interleave
• Allocates the buffer pool at startup
• “Replaces” innodb_buffer_pool_populate
• Default off
• “For the innodb_numa_interleave option to be available,
MySQL must be compiled on a NUMA-enabled Linux system
MariaDB : only custom builds MDEV-12924

27. CONFIG / VARIABLES 1/2
• Buffer pool size
• Query cache off
• Use a thread pool
• Cache the tables
• Cache threads
• Per thread memory usage
• Default storage engine
• Buffer pool contention

28. CONFIG / VARIABLES 2/2
• Large redo logs
• IO capacity
• InnoDB flushing
• Thread concurrency
• InnoDB table spaces
• Transaction isolation
• Replication : sync_binlog
• Replication : parallel threads
• Connector configuration

29. INNODB BUFFER POOL SIZE
• innodb_buffer_pool_size
• Not too large for the data
• Do not swap !
• Beware of memory crash if swapping is disabled
• Active data <= innodb_buffer_pool_size <= 0.8 * RAM

30. DISABLE THE QUERY CACHE
• Single threaded cache, removed in 8.0
• Only if threads_running <= 4
• Becomes fragmented
• Cache should be in the App !
• Off by default from 5.6
• query_cache_type = 0
• query_cache_size =0
• Problem if qcache_free_blocks > 50k

31. ENABLE THE THREAD POOL
• https://www.percona.com/blog/2014/01/23/percona-server-
improve-scalability-percona-thread-pool/
• Stabilize TPS for high
concurrency
• Useful if threads_running
> hardware threads
• Decrease context switches
• Several connections for one
execution thread
• Acts as a Speed Limiter
• MySQL commercial,
Percona, MariaDB

32. TABLE CACHING
• table_open_cache
• not too small, not too big
• opened_tables / sec
• table_definition_cache
• do not forget to increase
• opened_table_definitions / sec
• table_cache_instances = 8 or 16 (MySQL and Percona only)
• innodb_open_files
• mdl_hash_instances = 256 (in 5.7, no more an issue)

33. THREAD CACHING
• Thread creation is expensive, so caching is important
• thread_cache_size
• decreases threads_created rate
• capped by max user processes (see OS limits)
• 5.7.2 refactors this code
• Default value is calculated in 5.7
• http://dev.mysql.com/doc/refman/5.7/en/server-system-
variables.html#sysvar_thread_cache_size

34. INNODB STORAGE ENGINE
• Should be the default storage engine
• Do not use MyISAM unless you know what you are doing
• The most advanced storage engine is InnoDB
• Scalable
• Temporary tables use InnoDB in 5.7
• the memory engine is still used when using less then
tmp_table_size

35. BUFFER POOL CONTENTION
• innodb_buffer_pool_instances >= 8
• Reduce rows_examined / sec (see Bug #68079)
• 8 is the default value in 5.6 !
• innodb_spin_wait_delay = 96 on high concurrency
• Use read only transactions when possible

36. LARGE REDO LOGS
• Redo logs defer the expensive changes to the data files
• Recovery time is no more an issue
• innodb_log_file_size = 2047M before 5.6
• innodb_log_file_size >= 2047M from 5.6
• Bigger is better for write QPS stability
• You want to avoid “furious flushing”
• innodb_log_files_in_group = 2 is usually fine

37. IO CAPACITY
• IO capacity should mirror device IO capacity in IOPS
• innodb_io_capacity should be larger for SSD
• Impacts flushing
• In 5.6, innodb_lru_scan_depth is per buffer pool instance
• so innodb_lru_scan_depth = innodb_io_capacity /
innodb_buffer_pool_instances
• Default innodb_io_capacity_max = min(2000, 2 * innodb_io_capacity)
• From 5.7, innodb_page_cleaners, default = 4

38. PER THREAD MEMORY USAGE
• Each thread allocates memory
• estimates = max_used_connections * (
read_buffer_size +
read_rnd_buffer_size +
join_buffer_size +
sort_buffer_size +
binlog_cache_size +
thread_stack +
2 * net_buffer_length … + n * tmp_table_size where n >= 0
)
For a more accurate measure, check the performance_schema memory metrics
or MariaDB select * from information_schema.processlist.

39. THREAD CONCURRENCY
• No thread pool :
• innodb_thread_concurrency = 16 - 32 in 5.5
• innodb_thread_concurrency = 36 in 5.6
• align to HW threads if less than 32 cores
• Thread pool :
• innodb_thread_concurrency = 0 (unlimited) is fine
• innodb_max_concurrency_tickets : higher for OLAP, lower for
OLTP

40. INNODB FLUSHING
• Redo logs :
• innodb_flush_log_at_trx_commit = 1 // best durability
• innodb_flush_log_at_trx_commit = 2 // better performance
• innodb_flush_log_at_trx_commit = 0 // best performance
• Data files only :
• innodb_flush_method = O_DIRECT // Linux, skips the FS cache
• Increase innodb_adaptive_flushing_lwm (fast disk)

41. INNODB_FILE_PER_TABLE
• Default value : 1 table = 1 table space = 1 ibd file
• Not so good for small tables.
• Good for large tables.
• Default value from 5.6, before all tables in system table space.
• From 5.7, a user defined table space can now host several tables.
• http://dev.mysql.com/doc/refman/5.7/en/create-tablespace.html

42. TRANSACTION ISOLATION
• Default = REPEATABLE-READS
• Oracle database, Sybase ASE default is READ-COMMITTED
• Less locking, no gap locks, less overhead
• transaction-isolation = REPEATABLE-READ
• If you enable READ-COMMITTED, make sure binlog_format=ROW.

43. REPLICATION DURABILITY
• Replication is crash safe from 5.6
• Replication state was stored in files
• Now stored in InnoDB tables in the mysql schema
• However the binary logs are stored on disk :
• sync_binlog = 1
• no reason not to use from 5.6

44. MULTI-THREADED REPLICATION
• MariaDB slave_parallel_threads
• MySQL / Percona : slave_parallel_workers
• >1 when lag is a concern
• For a recent comparison, see https://www.percona.com/live/data-
performance-conference-2016/sites/default/files/slides/
2016-04-21_plmce_mysql_parallel_replication-inventory_use-
case_and_limitations.pdf

45. CONNECTOR TUNING
• Connectors can also be tuned.
• JDBC property for maximum performance :
• userConfigs=maxPerformance
• Use if the server configuration is stable
• Removes frequent
• SHOW COLLATION
• SHOW GLOBAL VARIABLES
• Fast validation query : /* ping */

46. APPLICATION DESIGN 1/2
• Schema design
• Indexes at the right place
• Remove redundant indexes
• Reduce rows examined
• Reduce sent rows
• Minimize locking
• Minimize temporary tables (on disk)
• Minimize sorting on disk

47. APPLICATION DESIGN 2/2
• Avoid long running transactions
• Close prepare statements
• Close idle connection
• Do not use the information_schema in your app
• Views may not not good for performance
– temporary tables (on disk)
• Replace truncate with drop table / create table
• Tune the replication thread
• Cache data in the app
• Scale out, shard

48. SCHEMA DESIGN
• create a PK for each table !
• integer primary keys
• avoid varchar, composite for PK
• latin1 vs. utf8 vs. utf8mb4
• the smallest varchar for a column
• smallest data type for a column
• keep the number of partitions low (< 100, optimal
performance <10) in 5.6. No more an issue in 5.7.
• use compression for blob / text data types

49. INDEXES
• Fast path to data
• B-TREE, R-TREE (spatial), full text
• for sorting / grouping
• without temporary table
• covering indexes
• contain all the selected data
• save access to full record
• reduce random reads

50. REDUNDANT INDEXES
• Not good for write performance
• duplicated data
• resources to update
• confuse the optimizer
• Use SYS schema views
• schema_unused_indexes

51. REDUCE ROWS_EXAMINED
• Rows read from the storage engines
• Rows_examined
• slow query log
• P_S statement digests
• SYS schema
• Handler%
• show session status where variable_name like ‘Handler%’ or
variable_name like ‘%tmp%’;
• optimize if rows_examined > 10 * rows_sent
• usually due to missing indexes

52. REDUCE ROWS_SENT
• Found in the slow query log, the SYS schema
• Number of rows that are returned by queries to the clients
• rows_sent <= rows_examined
• Network / CPU expensive
• Client compression can help.
• Usually bad design.
• Use caching or LIMIT for UI
• No human can parse 10k rows

53. REDUCE LOCKING
• Locking has a performance impact because locks kept are in memory
• Can be seen in show engine innodb status
• UPDATE, SELECT FOR UPDATE, DELETE, INSERT SELECT
• Use a PK ref, UK ref to lock
• Avoid large index range and table scans
• Reduce rows_examined for locking SQL
• Commit when possible

54. TEMPORARY TABLES (ON DISK)
• Large temporary tables on disk
• handler_write (handler_tmp_write, handler_tmp_update in
MariaDB)
• created_tmp_disk_tables
• monitor tmpdir usage
• Frequent temporary tables on disk
• High created_tmp_disk_tables / uptime
• show global status like '%tmp%';
• Available in the SYS schema, select * from sys.statement_analysis

55. MIND THE SORT (ON DISK)
• Key status variable is :
• sort_merge_passes : it is a session variable
• if it occurs often, you can try to up sort_buffer_size
• find the query and fix it with an the index if possible
• http://dev.mysql.com/doc/refman/5.7/en/order-by-
optimization.html

56. LONG RUNNING (IDLE) TRANSACTIONS
• Usually the oldest transactions in show engine innodb status :
• High history_list_length (a status variable in MariaDB)
• Prevent the purge
• Decrease performance
• Can also prevent schema changes (due to MDL locks)
• Can block backups (FTWRL see MDEV-12620)

57. CLOSE PREPARE STATEMENTS
• com_stmt_prepare – com_stmt_close ~= 0

58. CLOSE IDLE CONNECTIONS
• Idle connections consume resources
• Either refresh or disconnect them

59. MISCELLANEOUS
• Do not use the information_schema in your App
• Replace truncate with drop table / create table due to
• Bug #68184 Truncate table causes innodb stalls, fixed in MySQL
8.0
• Views may not be good for performance
• temporary tables (on disk)
• joining other views
• Scale out, shard

60. CACHE DATA IN THE APP
• Good for CPU / IO
• Cache the immutable or the expiring !
• referential data
• memcached / redis
• Query cache can be disabled
• Identify frequent statements
• perl mysqldumpslow.pl –s c slow60s.log
• pt-statement-digest
• Possibly use proxies such as ProxySQL, MaxScale

61. MONITOR THE REPLICATION THREADS
• Slow query log with
• log-slow-slave-statements is now dynamic (Bug #59860) from
5.6.11
• MySQL and Percona only
• Performance_schema >= 5.6.14
• binlog_format = ROW
• show global status like ‘Handler%’
• SYS (on table scans), detect tables not having PK
• In case of issue with a particular table, check the MDL locks.
• MariaDB and 5.7 have a way to see them

62. MONITOR / MAINTAIN
• Monitor the database and OS
• Mine the slow query log
• Use the performance_schema and SYS schema
• Backup the database
• Upgrade regularly

63. MONITOR THE DATABASE
• essential for any professional DBA
• part of the tuning and change processes
• alerts
• graphs
• availability and SLAs
• the effect of tuning
• query analysis

64. MINE THE SLOW QUERY LOG
• Dynamic collection
• The right interval
• Top queries
• pt-schema-digest
• Sort by query time desc
• perl mysqldumpslow.pl –s t slow.log
• Sort by rows_examined desc
• Top queries at the 60s range

65. USE THE SYS SCHEMA
• the SYS schema:
• good entry point
• ready to use views
• IO / latency / waits / statement digests
• ideal for dev and staging
• https://github.com/mysql/mysql-sys
• sys 5.6 works with MariaDB 10.1
• overhead is acceptable in most cases (5% for P_S)

66. BACKUP THE DATABASE
• Backup is always required !
• Method depends on your business : logical vs. physical
• Verify the backup
• Decrease the overhead on prod
• LVM has an overhead
• mysqldump eats MySQL resources
• mysqlbackup / xtrabackup copy the data files and verify it
(in parallel)

67. OPTIMIZE THE DATABASE
• Fragmentation has an impact on performance
• internal fragmentation (inside table spaces)
• external fragmentation (on the file system)
• OPTIMIZE TABLE fixes it (see also Bug #57583)
• can be done online
• MariaDB has the iterative defragmentation patch from
Facebook / Kakao.
• https://mariadb.com/kb/en/defragmenting-innodb-
tablespaces/

68. MONITORING FRAGMENTATION
• There is no general formula
• except for fixed length records
• create table t_defrag like t;
insert into t_defrag select * from t limit 20000;
• Fragmentation if Avg_row_length(t) >
Avg_row_length(t_defrag)
• Avg_row_length from show table status

69. MONITORING FRAGMENTATION
• There is no general formula
• except for fixed length records
• create table t_defrag like t;
insert into t_defrag select * from t limit 20000;
• Fragmentation if Avg_row_length(t) >
Avg_row_length(t_defrag)
• Avg_row_length from show table status

70. UPGRADE POLICY
• Security vulnerability fixes
• Bug fixes
• Performance improvements
• Ready for the next GA
• Never upgrade without testing (see change process)
• can be automated
• the DBA is also a QA engineer !

71. POINTERS
• The MySQL manual
• bugs.mysql.com
• Percona’s blog
• https://planet.mysql.com/
• 50 tips to improve MySQL performance (2014)
• Dimitrik’s latest slides and blog
• Bill Karwin’s Tuning MySQL Its about performance (2015)
• Bill Karwin’s SQL anti-patterns
• https://www.percona.com/live/17/resources/slides are freely available !!!
• FOSDEM videos https://video.fosdem.org/2017/H.1309/
• MariaDB
• My blog : http://aadant.com/blog

72. QUESTIONS?