The following tutorial column of Pagoda will introduce to you how to achieve simple tuning of MySQL performance through the Pagoda panel. I hope it will be helpful to friends in need!
During the operation of PHP MYSQL architecture websites, various performance problems are often encountered, such as MySQL, PHP, CPU, disk IO, cache, etc., among which MySQL is the bottleneck. It is the most common and difficult to solve factor that affects website performance; usually, we use caching software such as redis and memcached to cache content. This is indeed one of the best solutions, but it requires the support of the website program. However, most commonly used website programs do not support or cannot perfectly support these caching software. Today we will talk about how to optimize MySQL performance through MySQL's own configuration adjustments to alleviate the MySQL bottleneck problem.
Preparation:
1. Pagoda Linux panel official version 5.2.0 (released on 2017/09/20) Beta version 5.2.4
2. MySQL 5.x
Usually MySQL tuning is divided into the following parts:
1. MySQL configuration parameter tuning (needs to be adjusted according to the website’s operating conditions)
2. Data table index tuning (effect Obviously, but usually excellent open source programs do not need to be adjusted)
3. SQL statement tuning (this is what programmers or DBAs do)
Today we mainly talk about how to cooperate with Pagoda To use the new functions of the panel to tune MySQL configuration parameters, let’s first look at two pictures:
(Picture 1)
(Picture 2)
##Obviously, (Figure 1) shows the current running status of MySQL, (Figure 2) shows the main configuration parameters of MySQL Next we will Let’s interpret these two pictures: 1. Number of active/peak connections (Figure 1) The current active connection is 1. Since the MySQL service started, the highest number of connections is 54; When the highest number of connections is close to or equal to max_connections in (Figure 2), max_connections should be increased appropriately. It should be noted that do not increase too much at once. It is recommended to increase by 50 each time and observe for a period of time. If it is not enough, continue to increase. 2. Thread cache hit rate The thread cache hit rate in (Figure 1) is 99.78%. If this value is less than 90%, it is recommended to increase the thread_cache_size in (Figure 2) appropriately. It is recommended Increase by 8 each time. 3. Index hit rate The index hit rate in (Figure 1) is 99.50%. If this value is less than 95%, it is recommended to increase the key_buffer_size in (Figure 2) appropriately. It is recommended that each time Increase 64. It should be noted that if your database uses the Innodb engine, you can ignore this option 4, Innodb index hit rate (Figure 1) Innodb index hit rate 100%. If this value is less than 95%, it is recommended to increase the innodb_buffer_pool_size in (Figure 2) appropriately. It is recommended to increase it by 64 each time. It should be noted that if your database does not use the Innodb engine, you can ignore this option5. Query cache hit rate MySQL query cache is a controversial function. I personally recommend that when you are using caching software such as redis and memcached, you can set query_cache_size to 0 in (Figure 2). Turn it off. When you are not using caching software, have extra memory usage, and database bottlenecks are obvious, you can try to turn on query caching. This is a function that relies heavily on data table structure and SQL statement optimization. If the data table structure and SQL The statements have been optimized for query caching, and its effect is still very good. 6. Create temporary tables to disk (Figure 1) The proportion of creating temporary tables to disk is 0.42%, which shows that most of the temporary tables are created in the memory, not too many To increase the cost of disk IO, it is recommended that when the proportion is greater than 2%, increase the tmp_cache_size in (Figure 1) appropriately. It is recommended to increase it by 32 each time. When the proportion is greater than 60%, give up. Some open source programs have not specifically optimized SQL statements. , so a large number of temporary tables will be opened during operation, and no matter how much cache is added, it will not be enough. 7. Open table When the open table in (Figure 1) is close to or equal to the table_open_cache in (Figure 2), table_open_cache can be increased appropriately, but if it is set It is likely to cause your program to frequently interrupt the MySQL connection. It is recommended that the value be within 1024 and the maximum value should not exceed 2048. 8. The amount of JOIN without index and the amount of JOIN without index If it is not 0, check the data table index. In fact, as long as there is no crazy increase, for example, how much does it increase in a day? Thousands can generally be ignored. After all, it is more appropriate for programmers or DBAs to optimize indexes. 9. Number of merges after sortingIf this value is increasing slowly, it is recommended to increase the sort_buffer_size in (Figure 2) appropriately. It is recommended to increase it by 512 each time, but the maximum should not exceed 8192. If this value keeps rising, increasing sort_buffer_size is useless, so give up. This is an option. The blame should be placed on the program developers.
10. Number of table locks
If the server has low CPU overhead and locks tables crazily, it is recommended that you convert all data tables to innodb, and remember to back up before conversion.
11. Optimization plan
This is a recommended optimization plan based on the memory size. It is only recommended to be used for basic reference values. Each configuration item should be adjusted according to the actual situation. .
Note: After saving the parameter configuration, it will not take effect immediately. Remember to restart the MySQL service.
The above is the detailed content of How to achieve simple MySQL performance tuning through the Pagoda Panel. For more information, please follow other related articles on the PHP Chinese website!