Dalam webinar ini, kami mengajak anda untuk mengenal proses tuning performa MySQL database. Kita akan melakukan review best practices, opsi konfigurasi yg penting, diskusi ttg inisial MySQL config file, monitoring dan lain lain.
Mari mengenal bagaimana menemukan kueri yang paling membutuhkan optimasi menggunakan laporan kinerja di MySQL Workbench, MySQL Enterprise Monitor, atau melalui sys schema.
Probably the first thing to keep in mind is that you should be very careful while following any best practices of performance tuning. The reason is, the environment those practices are applicable to will almost never be identical to yours and what sas said earlier may not hold true any longer for various reaons… like mysql version change or hardware configuration being different etc.
Next point is, don’t pay too much attention to the benchmarks provided by hardware and software providers. You should test YOUR environment, your application and benchmark… also keep monitoring and when you apply any changes, make one change at a time.
For example read_rnd_buffer_size was in 5.5 and earlier only used by MyISAM. But in 5.6 and later by all storage engines for Multi-Range Optimization.
For example read_rnd_buffer_size was in 5.5 and earlier only used by MyISAM. But in 5.6 and later by all storage engines for Multi-Range Optimization.
Safety vs performance: e.g. sync_binlog and innodb_flush_at_trx_commit
Using the default value also automatically gives you improved values when the default value is changed in new versions. But new options also often has values that are backward compatible so does not take advantage of new features.
InnoDB (and NDBCluster) will always have a “PRIMARY KEY” whether specified explicitly or not
The PRIMARY KEY can also be a NOT NULL unique index
Unsigned integers with auto_increment makes a good PRIMARY KEY for InnoDB.
If you use UUID like PRIMARY KEYs for InnoDB, consider re-order the components to have the time component first.
Same procedure as when investigating all kinds of issues
Everybody knows this but sometimes, we just don’t practice. It’s important to have an action plan and follow it. If something goes wrong, you have a record of what you did.
If you start to ignore monitoring alerts because “it’s not important”, sooner or later you will also ignore one that is important
I will not go into details here using the monitoring system for performance tuning as there are other talks dedicated to that – see the references later
This is one of the reports available in Workbench which gives you details of events which are doing most I/O
Used by MySQL Enterprise Monitor Query Analyzer by default in 5.6.14 and later
Enabled by default
DIGEST_TEXT is a normalized query equivalent to the queries returned by mysqldumpslow
Timings are in picoseconds – the sys schema has the format_time() function to convert to human readable text
Obviously you may have experiences from previous projects that you may want to take into account
But remember, MySQL may have changed since you deployed the last project
The InnoDB redo logs may also be a good candidate for spinning disks as it’s sequential I/O; the fsync rate will be deciding factor
Binary logs are also I/O intensive, but serial I/O
The paths can be reconfigured later
Make sure to allow for growth!
Can be changed dynamically in 5.7+
Drawback of “too large” redo log: slower crash recoveries
The INNODB_METRICS log_lsn_% counters are not enabled by default, but it is recommended to enable them. Thus the innodb_monitor_enable = '%‘ recommendation for the initial configuration file.
This example uses the default values for the InnoDB redo log size
There are other similar main thread states which are not an indication of an asynchronous flush
If you have problems with asynchronous flushing, upgrading may help you
Side note: you can make incremental backups with MySQL Enterprise Backup using exclusively the redo log – if so make sure it’s big enough to hold the changes between backups.
Not really a capacity setting, but important to consider when creating the initial configuration file as innodb_undo_tablespaces cannot be changed later
The undo logs can be I/O intensive – with random I/O
The maximum allowed number of undo tablespaces were reduced in 5.7 as 32 tablespaces are now reserved for temporary tables
Example of option that has changed meaning between releases
In 5.5. and earlier the sort buffer was allocated in full each time it was needed
Have seen cases where 1 was fastest or as fast as 0/2 (redo logs were on SSD)
Make sure your operating system and hardware is not lying about the flush-to-disk operation
Crash recovery works irrespectively of the setting, but with != 1 some transactions may be missing after the recovery