Network Security Internet Technology Development Database Servers Mobile Phone Android Software Apple Software Computer Software News IT Information

In addition to Weibo, there is also WeChat

Please pay attention

WeChat public account

Shulou

What are the 19 optimization methods commonly used in MySQL projects?

2025-03-31 Update From: SLTechnology News&Howtos shulou NAV: SLTechnology News&Howtos > Database >

Share

Shulou(Shulou.com)05/31 Report--

MySQL project commonly used 19 optimization methods are what, many novices are not very clear about this, in order to help you solve this problem, the following editor will explain in detail for you, people with this need can come to learn, I hope you can gain something.

A total of 19 common MySQL optimization methods are mentioned today.

1 、 EXPLAIN

To do MySQL optimization, we need to make good use of EXPLAIN to view the SQL execution plan.

Here's a simple example to mark (1, 2, 3, 4, 5) the data we want to focus on:

Type column, connection type. A good SQL statement should at least reach the range level. Put an end to the all level.

Key column, the index name used. If no index is selected, the value is NULL. Mandatory indexing can be adopted.

Key_len column, index length.

Rows column, number of rows scanned. The value is an estimate.

Extra column, detailed description. Note that the common unfriendly values are as follows: Using filesort,Using temporary.

2. IN should not contain too many values in the SQL statement

MySQL optimizes IN accordingly, that is, all the constants in IN are stored in an array that is sorted. However, if the number is higher, the consumption is also relatively large. Another example: select id from t where num in (1 between 2) for consecutive values, don't use in if you can, or use a connection instead.

3. The SELECT statement must specify the field name.

SELECT* adds a lot of unnecessary consumption (CPU, IO, memory, network bandwidth); increases the possibility of using overwritten indexes; and pre-breaks also need to be updated when the table structure changes. Therefore, it is required to put the field name directly after the select. Tips: can Wechat search: Java backend, follow and join our own communication group.

4. Use limit 1 when only one piece of data is needed

This is to make the type column in EXPLAIN reach the const type

5. if the index is not used in the sort field, sort as little as possible

6. If other fields in the restriction do not have an index, use or as little as possible.

If one of the fields on both sides of the or is not an index field, and the other condition is not an index field, it will cause the query not to move the index. In many cases, using union all or union (when necessary) instead of "or" will get better results.

7. Replace union with union all as much as possible

The main difference between union and union all is that the former needs to merge the result sets and then carry out unique filtering operation, which will involve sorting, increasing a large number of CPU operations, and increasing resource consumption and delay. Of course, the prerequisite for union all is that there is no duplicate data in both result sets.

8. Do not use ORDER BY RAND ()

Select id from `dynamic` order by rand () limit 1000; the above SQL statement can be optimized as follows: select id from `dynamic`t1 join (select rand () * (select max (id) from `dynamic`) as nid) T2 on t1.id > t2.nidlimit 1000

9. Distinguish between in and exists, not in and not exists

The SQL statement on the select * from table A where id in (select id from table B) is equivalent to the select * from table A where exists (select * from table B where table B.id= table A.id). The distinction between in and exists is mainly caused by the change in the driving order (which is the key to the performance change). If it is exists, then the outer layer table is the driver table and is accessed first. If it is IN, then the subquery is executed first. Therefore, IN is suitable for situations where the appearance is large and the inner table is small; EXISTS is suitable for situations where the appearance is small and the inner table is large. With regard to not in and not exists, the recommended use of not exists is not just a matter of efficiency, but there may be logic problems with not in. How to write a SQL statement instead of not exists efficiently? The original SQL statement: select colname... From A table where a.id not in (select b.id from B table) efficient SQL statement: select colname … From A table Left join B table on where a.id = the result set taken out by b.id where b.id is null is shown in the following figure, and table An is not in table B's data:

10. Use reasonable paging methods to improve the efficiency of paging.

Select id,name from product limit 866613, 20 when using the above SQL statement for paging, someone may find that as the amount of data in the table increases, paging queries directly using limit will become slower and slower. The method of optimization is as follows: you can take the id of the maximum number of rows of the previous page, and then limit the starting point of the next page according to this maximum id. In this column, the largest id on the previous page is 866612. SQL can be written as follows: select id,name from product where id > 866612 limit 20

11. Segmented query

In some user selection pages, the time range selected by some users may be too large, resulting in slow query. The main reason is that there are too many scan lines. At this time, you can use the program, segment query, loop traversal, merge the results to display. As shown in the following SQL statement, you can use a segmented query when the number of rows scanned is more than one million:

12. Avoid judging fields with null values in the where clause

The judgment of null causes the engine to abandon the use of indexes and perform a full table scan.

13. Fuzzy query with% prefix is not recommended

For example, LIKE "% name" or LIKE "% name%", this kind of query can cause the index to fail and perform a full table scan. But you can use LIKE "name%". Then how to query% name%? As shown in the following figure, although the index is added to the secret field, it is not used in the explain result:

So how to solve this problem? the answer: use full-text index. Select id,fnum,fdst from dynamic_201606 where user_name like'% zhangsan%'; is often used in our queries. With such a statement, the ordinary index can not meet the query requirements. Fortunately, in MySQL, there is a full-text index to help us. The SQL syntax for creating a full-text index is: ALTER TABLE `dynamic_ 201606` ADD FULLTEXT INDEX `idx_user_ name` (`user_ name`); the SQL statement for using a full-text index is: select id,fnum,fdst from dynamic_201606 where match (user_name) against ('zhangsan' in boolean mode)

Note: before you need to create a full-text index, contact DBA to determine whether it can be created. At the same time, we should pay attention to the difference between the writing of query statements and ordinary indexes.

Avoid expression operations on fields in the where clause

For example, arithmetic operations are performed on fields in select user_id,user_project from user_base where age*2=36;, which will cause the engine to abandon the use of indexes. It is recommended to change it to: select user_id,user_project from user_base where age=36/2

15. Avoid type conversion when the type of the column field is inconsistent with the type of the parameter passed in the implicit type conversion where clause. It is recommended to determine the parameter type in where first.

16. For federated indexes, follow the leftmost prefix rule

For columns, the index contains fields id, name, and school. You can use the id field directly, or in the order of id and name, but name;school cannot use this index. Therefore, when creating a federated index, we must pay attention to the order of the index fields, with the commonly used query fields at the front.

17. If necessary, you can use force index to force the query to walk an index

Sometimes the MySQL optimizer takes the index it sees fit to retrieve the SQL statement, but maybe the index it uses is not what we want. At this point, forceindex can be used to force the optimizer to use our index.

18. pay attention to the range query statement

For federated indexes, if there are scope queries, such as between, >,

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.

Views: 0

*The comments in the above article only represent the author's personal views and do not represent the views and positions of this website. If you have more insights, please feel free to contribute and share.

Share To

Wechat

© 2024 shulou.com SLNews company. All rights reserved.

12
Report