purpose:
By modifying the system parameters of Mysql according to the current status of the server, the existing resources of the server can be reasonably utilized, and the performance of MySQL can be improved reasonably.
2. Server parameters:
32G memory, 4 CPUs, each with 8 cores.
3. The current installation status of MySQL.
MySQL目前安装，用的是MySQL默认的最大支持配置。拷贝的是my-huge.cnf.编码已修改为UTF-8.具体修改及安装MySQL,可以参考<<Linux系统上安装MySQL 5.5>>帮助文档。
4. Modify MySQL configuration
Open the MySQL configuration file my.cnf
vi /etc/my.cnf
4.1 Introduction and modification of MySQL non-cache parameter variables
4.1.1 Modify the back_log parameter value: modify the default value of 50 to 500. (256kb per connection, occupied: 125M)
back_log=500
The back_log value indicates how many requests can be stored on the stack in a short period of time before MySQL temporarily stops answering new requests. In other words, if the connection data of MySql reaches max_connections, the new request will be stored in the stack to wait for a connection to release resources. The number of the stack is back_log. If the number of waiting connections exceeds back_log, it will not be Grant connection resources. It will report: unauthenticated user | xxx.xxx.xxx.xxx | NULL | Connect | NULL | login | NULL when the connected process.
The back_log value cannot exceed the size of the listening queue of the TCP/IP connection. If it exceeds, it is invalid. Check the size of the listening queue of the current system's TCP/IP connection. Command: cat /proc/sys/net/ipv4/tcp_max_syn_backlog The current system is 1024. For Linux systems, the recommended setting is an integer less than 512.
Modify system kernel parameters,) http://www.51testing.com/html/64/n-810764.html
To view the default back_log value of the current mysql system, the command:
show variables like 'back_log'; 查看当前数量
4.1.2 Modify the wait_timeout parameter value from the default 8 hours to 30 minutes. (Not used this time)
wait_timeout=1800（单位为妙）
My understanding of the parameter wait-timeout: the maximum time that the database connection of the MySQL client is idle.
To put it more generally, your MySQL connection will be forcibly closed when it is idle for more than a certain period of time. MySQL's default wait-timeout value is 8 hours, and the result value can be viewed through the command show variables like'wait_timeout';.
Setting this value is very meaningful. For example, your website has a large number of MySQL link requests (each MySQL connection costs memory resources), and a large number of connection requests are idle due to your program. , Consuming memory resources in vain, or causing MySQL to exceed the maximum number of connections and never being able to create new connections, resulting in "Too many connections" error. Before setting, you can check the status of your MYSQL (show processlist can be used). If you often find that there are a large number of Sleep processes in MYSQL, you need to modify the wait-timeout value.
interactive_timeout: The number of seconds the server waits for activity before closing an interactive connection. An interactive client is defined as a client that uses the CLIENT_INTERACTIVE option in mysql_real_connect().
wait_timeout: The number of seconds the server waits for activity before closing a non-interactive connection. When the thread starts, the session wait_timeout value is initialized according to the global wait_timeout value or the global interactive_timeout value, depending on the client type (defined by the connection option CLIENT_INTERACTIVE of mysql_real_connect()).
These two parameters must be used together. Otherwise, setting wait_timeout alone is invalid
4.1.3 Modify the max_connections parameter value from the default 151 to 3000 (750M).
max_connections=3000
max_connections refers to the maximum number of connections for MySql. If the number of concurrent connection requests of the server is relatively large, it is recommended to increase this value to increase the number of parallel connections. Of course, this is based on the situation that the machine can support, because if the number of connections is larger, the number of connections Since MySql will provide a connection buffer for each connection, the more memory will be spent, so the value must be adjusted appropriately, and the value cannot be increased blindly. You can use the'conn%' wildcard to view the number of connections in the current state to determine the value of this value.
The maximum number of connections allowed by the MySQL server is 16384;
View the current maximum number of connections in the system:
show variables like 'max_connections';
4.1…4 Modify the max_user_connections value from the default 0 to 800
max_user_connections=800
max_user_connections refers to the maximum connection of each database user
The maximum number of parallel connections for all clients of a certain account to connect to the MYSQL service in parallel. Simply put, it refers to the maximum number of connections that the same account can connect to the mysql service at the same time. Set to 0 means no limit.
The current default value is: 0 unlimited.
Here is an introduction to Max_used_connections by the way: it refers to the maximum number of parallel connections at the same time from the start of the mysql service to the present. It does not refer to the current connection status, but a comparison value. If at a certain time in the past, there were 1000 requests connected to the MYSQL service at the same time, and there were no such large concurrent requests, then Max_used_connections=1000. Please pay attention to the difference with max_user_connections in show variables. The default is 0 means infinite.
View max_user_connections value
show variables like 'max_user_connections';
4.1.5 Modify the thread_concurrency value from the current default value of 8 to 64
thread_concurrency=64
Whether the value of thread_concurrency is correct or not has a great impact on the performance of MySQL. In the case of multiple CPUs (or multiple cores), setting the value of thread_concurrency incorrectly will cause MySQL to not make full use of multiple CPUs (or multiple cores) and appear the same Only one cpu (or core) is working at a time.
Thread_concurrency should be set to 2 times the number of CPU cores. For example, if there is a dual-core CPU, the thread_concurrency should be 4; for 2 dual-core CPUs, the value of thread_concurrency should be 8.
For example: According to the configuration of our current system introduced above, we know that there are 4 CPUs, each of which has 8 cores. According to the above calculation rules, here should be: 4 8 2=64
View the system's current thread_concurrency default configuration command:
show variables like 'thread_concurrency';
4.1.6 Add skip-name-resolve, which is commented out by default, without this parameter.
skip-name-resolve
skip-name-resolve: Forbid MySQL to perform DNS resolution for external connections. Using this option can eliminate the time for MySQL to perform DNS resolution. But it should be noted that if this option is enabled, all remote host connection authorizations must use IP address mode, otherwise MySQL will not be able to process connection requests normally!
4.1.7 skip-networking, commented out by default. There is no such parameter. (This time useless)
skip-networking建议被注释掉，不要开启
Enabling this option can completely close MySQL's TCP/IP connection mode. If the WEB server accesses the MySQL database server through a remote connection, do not enable this option! Otherwise it will not be able to connect normally!
4.1.8 default-storage-engine (Set MySQL's default storage engine)
default-storage-engine= InnoDB (Set the InnoDB type, and you can also set the MyISAM type)
Set the default storage type for creating databases and tables
show table status like ‘tablename’显示表的当前存储状态值
View the storage status and default storage status of MySQL
show engines;
Create table and specify storage type
CREATE TABLE mytable (id int, title char(20)) ENGINE = INNODB;
Modify the table storage type:
Alter table tableName engine =engineName
Remarks: After setting, turn on the following:
# Uncomment the following if you are using InnoDB tables
innodb_data_home_dir = /var/lib/mysql
#innodb_data_file_path = ibdata1:1024M;ibdata2:10M:autoextend（要注释掉，否则会创建一个新的把原来的替换的。）
innodb_log_group_home_dir = /var/lib/mysql
# You can set .._buffer_pool_size up to 50 - 80 %
# of RAM but beware of setting memory usage too high
innodb_buffer_pool_size = 1000M
innodb_additional_mem_pool_size = 20M
# Set .._log_file_size to 25 % of buffer pool size
innodb_log_file_size = 500M
innodb_log_buffer_size = 20M
innodb_flush_log_at_trx_commit = 0
innodb_lock_wait_timeout = 50
After setting, remember to delete ib_logfile0 and ib_logfile1 under the address of the MySQL installation directory (we are currently installed by default, so the address is /var/lib/mysql/). Otherwise, restarting MySQL fails to start.
4.2 Introduction and modification of MySQL cache variables
The database is an IO-intensive application, and its main responsibility is data management and storage. And we know that the time to read a database from memory is at the level of microseconds, while reading an IO from an ordinary hard disk is at the level of milliseconds. The difference between the two is 3 orders of magnitude. Therefore, to optimize the database, the first step that needs to be optimized is IO, as much as possible to convert disk IO into memory IO. This article first looks at which parameters can be used for IO optimization from the perspective of MySQL database IO related parameters (cache parameters)
4.2.1 Global Cache
A global cache that is allocated when MySQL is started and always exists. Currently there are: key_buffer_size (default value: 402653184, which is 384M), innodb_buffer_pool_size (default value: 134217728 which is 128M), innodb_additional_mem_pool_size (default value: 8388608 which is 8M), innodb_log_buffer_size (default value: 8388608 which is 8M (default value: 8388608), query_cache_size), Value: 33554432 ie: 32M) and so on five. Total: 560M.
These variable values can be viewed through commands such as: show variables like'variable name';.
4.2.1.1: key_buffer_size, this system is currently 384M, can be modified to 400M
key_buffer_size=400M
key_buffer_size is the size of the buffer used for the index block. Increasing it can get a better index (for all reads and multiple rewrites), which has the greatest impact on the performance of MyISAM (a type of MySQL table storage, you can view the details on Baidu, etc.) One of the parameters. If you make it too large, the system will start to page and really slow down. Strictly speaking, it determines the speed of database index processing, especially the speed of index reading. For servers with a memory of about 4GB, this parameter can be set to 256M or 384M.
How can I know whether the setting of key_buffer_size is reasonable? Generally, you can check the status values of Key_read_requests and Key_reads. The ratio of key_reads / key_read_requests should be as low as possible, such as 1:100, 1:1000, 1:10000. Its value can be checked with the following command: show status like'key_read%';
For example, view the current key_read and key_read_request values of the system:
+-------------------+-------+
| Variable_name | Value |
+-------------------+-------+
| Key_read_requests | 28535 |
| Key_reads | 269 |
+-------------------+-------+
It is known that there are 28535 requests and 269 requests are not found in the memory and directly read the index from the hard disk.
The probability of a cache miss is: 0.94%=269/28535*100%. Generally, the probability of a miss is better than 0.1. It is far greater than 0.1, which proves that the effect is not good. If the hit rate is below 0.01, it is recommended to modify the key_buffer_size value appropriately.
http://dbahacker.com/mysql/innodb-myisam-compare (Six differences between InnoDB and MyISAM)
http://kb.cnblogs.com/page/99810/ (see the storage engine introduction)
MyISAM、InnoDB、MyISAM Merge引擎、InnoDB、memory(heap)、archive
4.2.1.2: innodb_buffer_pool_size (default 128M)
innodb_buffer_pool_size=1024M(1G)
innodb_buffer_pool_size: The parameter that has the greatest impact on the performance of InnoDB tables. The function is the same as Key_buffer_size. The memory occupied by InnoDB, in addition to innodb_buffer_pool_size used to store page cache data, there is also about 8% overhead under normal circumstances, mainly used in the description of each cache page frame, adaptive hash and other data structures, if it is not safe to close, start If you need to recover from time to time, another 12% of the memory needs to be used for recovery, and the two add up to almost 21% of the overhead. Assumption: Innodb_buffer_pool_size of 12G, InnoDB may occupy 14.5G of memory at most. If the system only has 16G, and only runs MySQL, and MySQL only uses InnoDB,
Then open 12G for MySQL to maximize the use of memory.
In addition, InnoDB and MyISAM storage engines are different. MyISAM's key_buffer_size can only cache index keys, while innodb_buffer_pool_size can cache data blocks and index keys. Appropriately increasing the size of this parameter can effectively reduce the disk I/O of InnoDB tables.
When we operate an InnoDB table, all the returned data or any index block used in the process of data removal will go through this memory area.
The cache hit rate can be calculated by (Innodb_buffer_pool_read_requests – Innodb_buffer_pool_reads) / Innodb_buffer_pool_read_requests * 100%, and the innodb_buffer_pool_size parameter size can be adjusted for optimization according to the hit rate. The value can be checked with the following command: show status like'Innodb_buffer_pool_read%';
For example, view the current system in the system
| Innodb_buffer_pool_read_requests | 1283826 |
| Innodb_buffer_pool_reads | 519 |
+---------------------------------------+---------+
Its hit rate is 99.959%=(1283826-519)/1283826*100%. The higher the hit rate, the better.
4.2.1.3: innodb_additional_mem_pool_size (default 8M)
innodb_additional_mem_pool_size=20M
innodb_additional_mem_pool_size sets the size of the memory space used by the InnoDB storage engine to store data dictionary information and some internal data structures, so when we have a lot of database objects in a MySQL Instance, we need to adjust the size of this parameter appropriately to ensure that all data is Can be stored in memory to improve access efficiency.
Whether this parameter size is sufficient is relatively easy to know, because when it is too small, MySQL will record Warning information in the error log of the database, and then you know that you need to adjust the size of this parameter.
Check the error log cat /var/lib/mysql/machine name.error of the current system mysql and find that there are many waring warnings. So it needs to be adjusted to 20M.
According to the MySQL manual, for a machine with 2G memory, the recommended value is 20M.
100M of 32G RAM
4.2.1.4: innodb_log_buffer_size (default 8M)
innodb_log_buffer_size=20M
innodb_log_buffer_size This is the buffer used by the transaction log of the InnoDB storage engine. Similar to the Binlog Buffer, when InnoDB writes the transaction log, in order to improve performance, it also writes the information to the Innofb Log Buffer first. Only after the corresponding conditions set by the innodb_flush_log_trx_commit parameter (or the log buffer is full) will it be written The log is written to a file (or synchronized to a disk). The maximum memory space that can be used can be set through the innodb_log_buffer_size parameter.
The size of the buffer before InnoDB writes the log to the log disk file. The ideal value is 1M to 8M. The large log buffer allows the transaction to run without saving the log to disk but only until the transaction is committed (commit). Therefore, if there is a large transaction processing, setting a large log buffer can reduce disk I/O. Set in number format in my.cnf.
The default is 8MB, and it can be appropriately increased to 4MB～8MB for frequent systems. Of course, as mentioned above, this parameter is actually related to other flush parameters. Generally speaking, it is not recommended to exceed 32MB
Note: The innodb_flush_log_trx_commit parameter has a very critical impact on the write performance of InnoDB Log. The default value is 1. This parameter can be set to 0, 1, 2, and the explanation is as follows:
0: The data in the log buffer will be written to the log file at a frequency of once per second, and the file system will be synchronized to the disk at the same time, but the commit of each transaction will not trigger any log buffer to log file. Refresh or file system to disk refresh operation;
1: The data in the log buffer will be written to the log file every time a transaction is submitted, and it will also trigger the synchronization of the file system to the disk;
2: Transaction commit will trigger the flushing of log buffer to log file, but it will not trigger the synchronization of the disk file system to the disk. In addition, there will be a file system to disk synchronization operation every second.
The actual test found that this value has a great influence on the speed of inserting data. When it is set to 2, it only takes 2 seconds to insert 10000 records, when it is set to 0, it only takes 1 second, and when it is set to 1, it takes 229 seconds. Therefore, the MySQL manual also recommends combining insert operations into one transaction as much as possible, which can greatly increase the speed. According to the MySQL manual, this value can be set to 0 if there is a risk of losing the most recent transaction.
4.5.1.5: query_cache_size (default 32M)
query_cache_size=40M
query_cache_size: Mainly used to cache the ResultSet in MySQL, which is the result set of a SQL statement execution, so it can only be used for select statements. When we turn on the Query Cache function, after MySQL receives a request for a select statement, if the statement meets the requirements of Query Cache (not explicitly stated that Query Cache is not allowed, or that the use of Query Cache has been explicitly stated), MySQL It will directly hash the received select statement as a string according to the preset HASH algorithm, and then directly check whether it has been cached in the Query Cache. In other words, if it is already in the cache, the select request will directly return the data, thus omitting all subsequent steps (such as SQL statement parsing, optimizer optimization, and requesting data from the storage engine, etc.), which greatly improves performance. According to the MySQL user manual, using query buffering can achieve an efficiency of up to 238%.
Of course, Query Cache also has a fatal flaw, that is, any change in the data of a table will cause all the select statements that reference the table to invalidate the cached data in the Query Cache. Therefore, when our data changes very frequently, using Query Cache may not outweigh the gains
The use of Query Cache requires the cooperation of multiple parameters. The most important ones are query_cache_size and query_cache_type. The former sets the memory size for caching the ResultSet, and the latter sets the context in which Query Cache is used. In the past experience, if it is not a MySQL database for caching basically unchanged data, query_cache_size is generally 256MB is a more appropriate size. Of course, this can be adjusted by calculating the hit rate of Query Cache (Qcache_hits/(Qcache_hits+Qcache_inserts)*100)). The query_cache_type can be set to 0 (OFF), 1 (ON) or 2 (DEMOND), respectively, which means that the query cache is not used at all. All the selects except the explicit request not to use the query cache (using sql_no_cache) use the query cache. Use query cache (using sql_cache) only when required to display. If the value of Qcache_lowmem_prunes is very large, it indicates that buffering occurs frequently. If the value of Qcache_hits is also very large, it indicates that the query buffer is used very frequently, and the buffer size needs to be increased at this time;
Adjust according to the hit rate (Qcache_hits/(Qcache_hits+Qcache_inserts)*100)). Generally, it is not recommended to be too large. 256MB may be almost the same. Large configuration static data can be adjusted appropriately.
You can use the command: show status like'Qcache_%'; to view the current system Query catch usage size
| Qcache_hits | 1892463 |
| Qcache_inserts | 35627
98.17% hit rate=1892463/(1892463 +35627 )*100
4.2.2 Local cache
In addition to the global buffer, MySql will also issue a connection buffer for each connection. Each thread connecting to the MySQL server needs to have its own buffer. Probably need to allocate 256K immediately, even when the threads are idle, they use the default thread stack, network cache, etc. After the transaction begins, more space needs to be added. Running a small query may only add a small amount of memory consumption to the specified thread. However, if you do complex operations on the data table such as scanning, sorting or requiring temporary tables, you need to allocate about read_buffer_size,
Sort_buffer_size, read_rnd_buffer_size, tmp_table_size memory space. But they are only allocated when needed, and released after those operations are completed. Some are immediately allocated into separate chunks. tmp_table_size may be as high as the maximum memory space MySQL can allocate for this operation
. Note that there is more than one thing to consider here-multiple caches of the same type may be allocated, for example to process subqueries. The memory usage of some special queries may be larger-if batch inserts are made on the MyISAM table
When you need to allocate bulk_insert_buffer_size memory; execute ALTER TABLE, OPTIMIZE TABLE, REPAIR TABLE commands need to allocate myisam_sort_buffer_size memory.
4.2.2.1: read_buffer_size (default value: 2097144 or 2M)
read_buffer_size=4M
read_buffer_size is the size of the buffer that MySql reads. The request for sequential scan of the table will allocate a read buffer, and MySql will allocate a memory buffer for it. The read_buffer_size variable controls this
The size of the buffer. If the sequential scan requests for the table are very frequent, and you think that frequent scans are too slow, you can improve its performance by increasing the value of this variable and the size of the memory buffer.
4.2.2.2: sort_buffer_size (default value: 2097144 or 2M)
sort_buffer_size=4M
sort_buffer_size is the buffer size used by MySql to perform sorting. If you want to increase the speed of ORDER BY, first see if you can make MySQL use indexes instead of an additional sorting stage. If not, you can try to increase the size of the sort_buffer_size variable
4.2.2.3: read_rnd_buffer_size (default value: 8388608 or 8M)
read_rnd_buffer_size=8M
read_rnd_buffer_size is the random read buffer size of MySql. When the rows are read in any order (for example, in the sort order), a random read buffer will be allocated. When sorting and querying, MySql will scan the buffer first to avoid disk search and increase the query speed. If you need to sort a large amount of data, you can increase the value appropriately. But MySql will issue the buffer space for each client connection, so you should try to set this value appropriately to avoid memory opening.
The pin is too large.
4.2.2.4: tmp_table_size (default value: 8388608 ie: 16M)
tmp_table_size=16M
tmp_table_size is the heap (stacked) table buffer size of MySql. All unions are completed in one DML instruction, and most unions can even be completed without temporary tables. Most temporary tables are based on
The saved (HEAP) table. Temporary tables with large record lengths (the sum of the lengths of all columns) or tables containing BLOB columns are stored on the hard disk. If the size of an internal heap (stacked) table exceeds tmp_table_size, MySQL can automatically
Automatically change the heap table in the memory to a MyISAM table based on the hard disk. You can also increase the size of the temporary table by setting the tmp_table_size option. In other words, if you increase the value, MySql will increase the size of the heap table at the same time, which can be improved
The effect of link query speed.
4.2.2.5: record_buffer: (default value:)
Record_buffer each thread that performs a sequential scan allocates a buffer of this size for each table it scans. If you do a lot of sequential scans, you may want to increase this value. The default value is 131072
(128K)
4.2.3 Other cache:
4.2.3.1: table_cache (default: 512)
TABLE_CACHE (also known as TABLE_OPEN_CACHE in 5.1.3 and later versions)
table_cache specifies the size of the table cache. Whenever MySQL accesses a table, if there is room in the table buffer, the table is opened and put into it, so that the table contents can be accessed faster. By checking the state values Open_tables and Opened_tables of the peak time, you can determine whether you need to increase the value of table_cache. If you find that open_tables is equal to table_cache, and opened_tables is increasing, then you need to increase the value of table_cache (the above status value can be obtained using SHOW STATUS LIKE'Open%tables'). Note that you cannot blindly set table_cache to a large value. If it is set too high, it may cause insufficient file descriptors, resulting in unstable performance or connection failure.
SHOW STATUS LIKE 'Open%tables';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| Open_tables | 356 |
| Opened_tables | 0 |
+---------------+-------+
2 rows in set (0.00 sec)
open_tables represents the number of table caches currently open. If the flush tables operation is executed, the system will close some of the table caches that are not currently in use to reduce the value of this state;
opend_tables represents the number of table caches that have been opened, and will always be accumulated. If the flush tables operation is executed, the value will not decrease.
In the case of mysql default installation, the value of table_cache is 256 to 512 by default in a machine with 2G memory. If the machine has 4G memory, the default value is 2048, but this definitely means the larger the machine memory, this value It should be larger, because after table_cache is increased, mysql responds to SQL faster, inevitably, more deadlocks (dead lock) will be generated, which will slow down the entire set of database operations, which will seriously affect performance. Therefore, in normal maintenance, you still have to make judgments based on the actual situation of the library, and find the table_cache value that is most suitable for the library you maintain.
Since MySQL is a multi-threaded mechanism, in order to improve performance, each thread opens the file descriptor of the table it needs independently, instead of sharing it. The method of processing for different storage engines is of course different.
In the myisam table engine, the descriptor of the data file is not shared, but the descriptor of the index file is shared by all threads. Innodb is related to the type of table space used, if it is a shared table space, then there is actually one Data files, of course, occupy less data file descriptors than independent table spaces.
The recommended size given in the mysql manual is: table_cache=max_connections*n
n represents the maximum number of tables in the query statement, and some additional file descriptors need to be reserved for temporary tables and files.
This data has been questioned a lot, just enough table_cache is good enough, check the value of Opened_tables, if this value is very large, or if it grows quickly, then you have to consider increasing table_cache.
table_cache: The number of tables opened by all threads. Increasing this value can increase the number of file descriptors required by mysqld. The default value is 64.
4.2.3.2 thread_cache_size (server thread cache)
thread_cache_size=64
The default thread_cache_size=8, but the values in many configuration examples are generally 32, 64, or even 128. I feel that this parameter should be helpful for optimization, so I checked:
According to the investigation, it is found that the thread_cache_size of the server thread cache is not set, or the setting is too small. This value indicates that the number of threads stored in the cache can be reused. If there is space in the cache when the connection is disconnected, the client thread will be put In the cache, if the thread is requested again, the request will be read from the cache. If the cache is empty or a new request, then the thread will be recreated. If there are many new threads, increase this value. Improve system performance. By comparing Connections and Threads_created state variables, you can see the role of this variable. (–> indicates the value to be adjusted) According to the physical memory setting rules as follows:
1G —> 8
2G —> 16
3G —> 32 >3G —> 64
mysql> show status like 'thread%';
+——————-+——-+
| Variable_name | Value |
+——————-+——-+
| Threads_cached | 0 | <—当前被缓存的空闲线程的数量
| Threads_connected | 1 | <—正在使用（处于连接状态）的线程
| Threads_created | 1498 | <—服务启动以来，创建了多少个线程
| Threads_running | 1 | <—正在忙的线程（正在查询数据，传输数据等等操作）
+——————-+——-+
Check how many times the database has been connected after booting up?
mysql> show status like '%connection%';
+———————-+——-+
| Variable_name | Value |
+———————-+——-+
| Connections | 1504 | –>服务启动以来，历史连接数
| Max_used_connections | 2 |
+———————-+——-+
Judge whether the setting value is appropriate by the hit rate of the connection thread pool? The hit rate is more than 90%, and the setting is reasonable.
(Connections - Threads_created) / Connections * 100 %
Author: A dodge the
link: https: //www.jianshu.com/p/c88a45c2f642