How to achieve simple MySQL performance tuning through the Pagoda Panel

During the operation of the PHP MYSQL architecture website, there are often Encountered various performance problems, such as MySQL, PHP, CPU, disk IO, cache, etc. Among them, MySQL bottleneck is the most common and difficult to solve factor that affects website performance; usually, we will use redis, memcached and other caches Software to cache content is indeed one of the best solutions, but it requires the support of website programs. However, most commonly used website programs do not support or cannot perfectly support these caching software. Today we will talk about how to use MySQL itself Configuration adjustments to optimize MySQL performance to alleviate MySQL bottlenecks.

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, we divide MySQL tuning into the following parts:

1. MySQL configuration parameter tuning (needs to be adjusted according to the operation of the website)

2. Data Table index tuning (the effect is obvious, 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 tune MySQL configuration parameters with the new functions of the Pagoda Panel. Let's first look at two pictures

Obviously, (Figure 1) shows the current running status of MySQL, (Figure 2) shows the main configuration parameters of MySQL

Let’s interpret these two Figure:

1. Number of active/peak connections (Figure 1) There is currently 1 active connection. Since the MySQL service was started, the highest number of connections is 54; when the highest number of connections is close to or equal to (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 it by 50 each time and observe it for a period of time. If it is not enough, continue to increase it.

2. 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 to increase it by 8 each time.

3. Index hit rate (Figure 1) The index hit rate 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 to increase it by 64 each time. Please explain. Yes, if your database uses the Innodb engine, you can ignore this option

4. Innodb index hit rate (Figure 1) The Innodb index hit rate is 100%. If this value is less than 95%, it is recommended to use it appropriately. Increase innodb_buffer_pool_size in (Figure 2). 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 option

5. Query cache hit rate MySQL query cache is a comparison Controversial function, I personally recommend that when you are using caching software such as redis, memcached, etc., you can turn it off by setting query_cache_size to 0 in (Figure 2). When you are not using caching software and there is excess memory usage, and When database bottlenecks are obvious, you can try to enable query caching. This is a function that relies heavily on data table structure and SQL statement optimization. If the data table structure and SQL statements are optimized for query caching, the 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 temporary tables are created in memory and will not increase disk IO overhead too much. 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 during operation A large number of temporary tables will be opened, and no amount of caching will 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), you can increase table_open_cache appropriately, but if the setting is too large, it may cause your program to Frequently interrupt MySQL connections, it is recommended to be within 1024, and the maximum should not exceed 2048.

8. The amount of unused indexes and unused JOIN amounts. If it is not 0, check the data table index. In fact, as long as it does not increase dramatically, such as increasing by thousands a day, it can generally be ignored. After all, it is more appropriate for programmers or DBAs to optimize indexes.

9. The number of merges after sorting If 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 has been rising rapidly, increase sort_buffer_size is useless, so just give up this option. This blame should be left to the program developers.

10. Number of table locks If the server's CPU overhead is low and the table is locked like crazy, 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.