Source: https: //zhuanlan.zhihu.com/p/49888088
In this article we talk about MySQL optimization methods commonly used in the project, a total of 19, as follows:
1、EXPLAIN
MySQL optimization to do, we have to make good use of EXPLAIN view SQL execution plan.
Let's a simple example, labeling (1,2,3,4,5) data we need to focus on:
-
type column , the type of connection. A good SQL statement to reach at least the level range. Prevent the emergence of all levels.
-
The key column, use the name of the index. If you do not select an index, the value is NULL. It may take enforcement indexing.
-
key_len column index length.
-
rows columns, the number of scanning lines. This value is an estimate.
-
extra columns detail. Note that common values are less friendly, as follows: Using filesort, Using temporary.
2, the value contained in the SQL statement should not be overloaded IN
For MySQL made the corresponding optimized IN, IN upcoming constants in all stored in an array inside, and the array is sorted.
However, if the value is more, consume generated is relatively large.
Another example: select id from t where num in (1,2,3) for successive values, can not use in the between; used to replace or re-connected.
3, SELECT statement is sure to specify the name of the field
SELECT * increase the number of unnecessary consumption (CPU, IO, memory, network bandwidth); increases the possibility of using a covering index; and when the table structure changes, need to update before breaking.
So I requested directly connected to the back of the field names in the select.
4, when only a required data using limit 1
This is to achieve the type column in EXPLAIN const type
5, if the sort field is not used in the index, as little as possible to sort
6, if there is no constraint index of other fields, or minimize the use of
or both sides of the field, if there is not a field index, while other conditions are not indexed field, the situation will cause the query does not go indexes.
Many times using union all or union (when necessary) way to replace "or" will get better results.
7, instead of the union with the union all possible
Union and union all differences are mainly the former requires the collection of the results and then uniqueness of the filtering operation, which will involve sorting, increase the number of CPU operations, increase resource consumption and latency.
Of course, with the proviso that two union all the result data set is not repeated.
8, without using ORDER BY RAND ()
select id from `dynamic` order by rand() limit 1000;
SQL statement above, can be optimized for:
select id from `dynamic` t1 join (select rand() * (select max(id) from `dynamic`) as nid) t2 on t1.id > t2.nidlimit 1000;
9, the distinction between in and exists, not in and not exists
select * from 表A where id in (select id from 表B)
The above SQL statement is equivalent to:
select * from 表A where exists(select * from 表B where 表B.id=表A.id)
Distinction exists mainly in and caused the driver to change the order (which is the key performance variations), if it exists, then the outside layer of table-driven table is accessed first, if it is IN, it runs the subquery.
IN adapted so large and small outer inner case; EXISTS adapted to the outer case of the small and large table.
About not in and not exists, we recommended not exists, not only efficiency, not in logic there may be a problem.
How efficient alternative not exists write a SQL statement?
Original SQL statement:
select colname … from A表 where a.id not in (select b.id from B表)
Efficient SQL statement:
select colname … from A表 Left join B表 on a.id = b.id and b.id is null
Remove the result set as shown below indicates, A table is not the data in Table B:
10, the use of reasonable methods to increase the efficiency of pagination pagination
select id,name from product limit 866613, 20
When using the SQL statement to do paging, some people may find that, with the increasing amount of table data, use direct query page limit will become slower.
Optimization method is as follows:
It can be taken before a maximum number of rows id, then to limit the starting point of the next page according to the biggest id. So the column than the largest previous id is 866612.
SQL can be written as follows:
select id,name from product where id> 866612 limit 20
11, sub-query
In some user selection page, some users may select the time frame is too large, resulting in a slow query.
The main reason is the excessive number of scanning lines. This time can be programmed, segmentation query, loop through the results consolidation process on display.
The SQL statement shown below, the number of scanning lines to more than one million when you can use segmentation query:
12, to avoid a null value fields in the where clause determines
For null judgment will cause the engine to give up using the index and full table scan.
13% are not recommended prefix fuzzy queries
For example LIKE "% name" or LIKE "% name%", such a query can lead to failure while the index for full table scan.
But you can use LIKE "name%".
How that query% name% of it?
As shown below, although the index is added to the secret field, but did not explain the results in:
So how to solve this problem, the answer is: Use full-text indexing.
In our queries often use the select id, fnum, fdst from dynamic_201606 where user_name like '% zhangsan%';.
Such a statement, the general index is unable to meet the needs of the inquiry. Fortunately, in MySQL, full-text indexing to help us.
Create a full-text index of SQL syntax is:
ALTER TABLE `dynamic_201606` ADD FULLTEXT INDEX `idx_user_name` (`user_name`);
Use full-text indexing SQL statement is:
select id,fnum,fdst from dynamic_201606 where match(user_name) against('zhangsan' in boolean mode);
Note: Before you need to create full-text indexes, please contact the DBA to determine whether created. Also of note is the query written statement with the general index difference.
14, to avoid operation in fields where clause expression
such as:
select user_id,user_project from user_base where age*2=36;
In the field of arithmetic operations on the line, which can cause the engine to give up using the index, the proposed change:
select user_id,user_project from user_base where age=36/2;
15, to avoid the implicit type conversion
where clause appears type conversion type column fields and inconsistent when an incoming parameter type occurs, it is recommended to determine the parameters of the type where.
16, for the joint index, the most left-prefix to comply with the law
For column contains fields for index id, name, school, id field can be directly used, may be id, name in this order, but the name; school can not use this index.
Therefore, when creating the joint index must pay attention to the order of the index fields, commonly used in the query field on the front.
17, can use force index, if necessary, to force an index query go
Sometimes MySQL optimizer to take it considers appropriate index to retrieve the SQL statement, but it may be used in the index is not what we want.
Then you can use forceindex to force the optimizer to use the index we have developed.
18, note that the scope of the query
For the joint index, if there is range queries, such as between,>, <when other conditions, can cause failure of the back of the index field.
19, on JOIN Optimization
LEFT JOIN A table-driven table, INNER JOIN MySQL will automatically find little effect of the data table driving table, RIGHT JOIN B table-driven table.
note:
1) MySQL is not full join, you can use the following ways to solve:
select * from A left join B on B.name = A.namewhere B.name is nullunion allselect * from B;
2) make use of inner join, avoid left join:
Table participation in joint inquiry of at least two tables, there are generally the size of the points.
If the connection is inner join, MySQL will automatically choose a small table in the absence of other filters situation as the driving table, but left join followed in the choice of driving table is the principle of the left drive to the right, that left join the table name on the left driven table.
3) rational use of the index:
Table index field is driven as a limitation on the field.
4) the use of a small table to drive a large table:
From the diagram can be directly see if it is possible to reduce the drive table, reduce the number of nested loops in the loop, to reduce the number and the total amount of CPU IO operations.
5）巧用 STRAIGHT_JOIN：
inner join table is selected by the MySQL driver, but there are some special circumstances need to select another table as the driving table, such as a group by, order by, etc. "Using filesort" when "temporary Using."
STRAIGHT_JOIN to force the join order, in the table is the driving table STRAIGHT_JOIN left, the right is being driven table.
In use STRAIGHT_JOIN there is a proviso that the query is an inner join, is the inner join.
Other links are not recommended STRAIGHT_JOIN, or it may cause inaccurate results.
This approach can sometimes reduce 3 times longer.
·END·
Programmers growth path
Although the road is far, certainly the line to
本文原发于 同名微信公众号「程序员的成长之路」，回复「1024」你懂得，给个赞呗。
回复 [ 520 ] 领取程序员最佳学习方式
回复 [ 256 ] 查看 Java 程序员成长规划