Shulou(Shulou.com)06/03 Report--

This article focuses on "MySQL optimization methods to improve efficiency", interested friends may wish to take a look. The method introduced in this paper is simple, fast and practical. Next let the editor to take you to learn "MySQL optimization to improve efficiency" bar!

1. EXPLAIN

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

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

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 overlay indexes; and front breaks also need to be updated when the table structure changes. Therefore, it is required to put the field name directly after the select.

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

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.

Do not use ORDER BY RAND ()

Distinguish between in and exists, not in and not exists

The difference between in and exists is mainly caused by the change of the driver 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, and 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?

Original sql statement

Select colname... From A form where a.id not in (select b.id from B form)

Efficient sql statement

Select colname... From A table Left join B table on where a.id = b.id where b.id is null

Use reasonable paging methods to improve the efficiency of paging

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.

Avoid judging the null value of a field in the where clause

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

XIII. 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%".

Avoid expression operations on fields in the where clause

Avoid implicit type conversions

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

For federated indexes, follow the leftmost prefix rule

For columns, the index contains the field id,name,school, either directly with the id field or in the same order as id,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.

If necessary, you can use force index to force a 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.

Pay attention to the scope query statement

For federated indexes, if there is a scope query, 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.