MySQL universal nested loop for each query are not optimal. However, MySQL query optimizer only small parts of the query does not apply, and we can often get MySQL query by rewriting the efficient completion of the work.
1 correlated subquery
MySQL subqueries to achieve very bad. Sub query where the worst conditions for a class contained in () query. Because a dedicated MySQL optimization strategy in () in the list of options, tend to think MySQL will perform the first sub-query returns all values in () clause in the query. In general, in () list query fast, so we thought this would perform sql
select * from tast_user where id in ( select id from user where name like ' King%');
we thought this would be resolved to the following sql form
select * from tast_user where id in ( 1,2,3,4,5);
actually is resolved MySQL
SELECT * from tast_user WHERE EXISTS
(SELECT User ID from WHERE name like 'King%' and tast_user.id the user.id =);
the MySQL table compression will be related to the sub-outer query, so that it can more efficiently find the data line.
This time due to the sub-query uses an external table id field so sub-query can not be executed first. Can be seen through explin, MySQL first choice for tast_user table full table scan, and then one by one to perform queries based on id child returned. If the outer layer is a big table, the performance of this query will be very bad. Of course, we can optimize the writing table:
select tast_user. * from tast_user inner join user using (tast_user.id) where user.name like ' % King'
Another way is to use optimized group_concat constructed in a list separated by commas (). This is sometimes associated with the use of rewriting faster than the above. Because of the use in () plus sub-queries, performance is usually very bad. It is generally recommended to use exists () equivalent rewritten query to get better efficiency.
How to write better in the sub-query is not introduced, because now basically requires split into single-table queries, and self-interested, then you can go about the next.
2 UNION restrictions
may, MySQL constraints can not be derived from the inner layer, which makes it possible to limit the portion of the original conditions return results can not be applied to the inner query optimization.
If desired the respective union clause can be taken according to the partial result set limit only, or to be able to merge the sorted result set, then it is necessary to use these clauses are each clause in the union. For example, we want to unite the two sub-query results, and then take the 20 before, so MySQL will be two tables are stored in a temporary table, then remove the first 20 rows.
(SELECT FIRST_NAME, last_name from actor Order by last_name) All Union
(SELECT FIRST_NAME, last_name from customer Order by last_name) 20 is limit;
recording this actor would query the customer table and all taken out on a temporary table and then at 20 from the former, respectively, by adding two sub-queries in a limit 20 to reduce the data in the temporary table.
Now in the middle of the temporary table will contain only 40 records, out of considerations other than performance, there is also need to note that: The order of data removed from the temporary table is not certain, therefore if you want get the correct order, also need to add order by operation of a global
third index combined optimization
previous sections already mentioned, MySQL access to a single table indexes to a plurality of combined filtering and cross need to find ways of locating a row.
4 equivalent transfer
some point, the equivalent transfer will bring some unexpected extra consumed. For example, there is a very large in () list, and MySQL optimizer found where / on or using clause, a column will be associated with this list of values and a table top.
The optimizer will be in () lists are assigned to each application in the associated table. Typically, each table as the new filter criteria, the optimizer can more funny filtered from the recording storage engine. But if the list is very large, it will lead to optimization and execution will slow down.
5 parallel execution
MySQL unable to take advantage of multi-core parallel query execution characteristics. Many other relational database Eng able to provide this feature, but MySQL can not do. Particularly I pointed out here is to remind you not to spend time trying to find a way to execute a query in parallel.
6 Hash association
in 20,113 years hash associated with the implementation of MySQL does, are all associated MySQL nested loops association. But can lead to realization curve associated hash If you are using Memory engine, the index is a hash index, so when the association is also similar to hash associated through the establishment of a hash index. In addition MariaDB has been achieved hash association.
7 loose index scan
due to historical reasons, MySQL does not support the loose index scan, according to the index will not be able to scan a discontinuous manner. Usually, MySQL index scan need to define a starting point and focus, even if the data need only a very few in this index, MySQL still need to scan the segment index for each entry.
Example: existing index (a, B)
SELECT * WHERE from Table 2 and B BETWEEN. 3;
as check field index is a, but only specified in the query field b, MySQL can not use this index, so that only by total table scan to find the matching rows. ,
MySQL a full table scan:
understand the weakness of the structure of the index, it may also be difficult to find a faster way to execute the query above. Inability storage engine index structure is not an API makes it possible to scan a range of b column in the first row corresponding to the value, and then jump to a different column of the second range of values corresponding to the scanning of the column b
at this time there is no need to use the where clause filter, because a loose index scan has cleared all unwanted recording.
The above is a simple example, a loose index scan process, a new index can of course also suitable to optimize the above query. But for some scenes, the index increase is useless, for example, for the first crack Solitude range conditions, Solitude split second is to build the equivalent submit queries by adding indexes can not solve the problem.
After MySQL5.6, some restrictions on the loose index scan would scare through the branch condition index is resolved.
8 maximum and minimum values optimized
for MIN () and MAX () query, MySQL optimization do not good, for example:
SELECT min (the actor_id) from the Actor WHERE FIRST_NAME = 'Wang'
Because in the first_name field and no index, so MySQL will conduct a full table scan. If MySQL is capable of scanning a primary key, then theoretically, when MySQL read the first record satisfying the conditions too, it is the minimum we need, because the primary key is strictly in accordance with the size of the brother of the sort actor_id field. But MySSQL then only do full table scan, we can be verified by a full table scan counter show status of that. A county optimization solution is to remove the min () function, then use limit 1 query.
This strategy allows MySQL to scan the number of records as little as possible. This example tells us that sometimes in order to achieve higher performance, you have to give up some principles.
9 queries and updates on the same table
MySQL does not allow the same table to query and update at the same time. This is not optimizer limits, if clear how MySQL is executing the query, you can avoid this situation. Example:
Update Table SET CNT = (SELECT COUNT (*) AS TB from Table WHERE tb.type = table.type);
the sql Although a single standard can not be performed, we can bypass the above limitations by using a generated table form, because MySQL will only put this table as a temporary table to deal with.
Inner the Join the Table Update
(the SELECT of the type, COUNT (*) AS cnt from the Table by Group of the type) AS a using TB (of the type)
the SET table.cnt = tb.cnt;
in fact, these two queries executed: a sub query select statement, the other is the NRL related update, the table only when associated with a temporary table. Sub-query is completed before the update statement opens the table, it will run properly.
Tip 10 query optimizer (hint)
If you do plan chosen by the optimizer are not satisfied, you can use the optimizer provides several tips (hint) to control the final implementation plan. The following are some common tips, and simply given when to use the tips. By adding a prompt response in the query, you can control the execution plan for the query.
① HIGH_PRIORITY and LOW_PRIORITY
this prompt to tell MySQL, when multiple statements simultaneously access a table, the priority of which statements of relatively higher and which statements relatively lower priority.
HIGH_PRIORITY time for the select statement, MySQL will reschedule this select statement to all tables are locked so that sentence before the data changes. MySQL is actually placed to the front of the queue table, rather than waiting in a conventional sequence. HIGH_PRIORITY can also be used to insert the statement, the effect is simply the effect of the global sports school setting LOW_PRIORITY the statement.
LOW_PRIORITY the contrary, it will make the statement has been in a wait state, as long as there is access to the same table in the queue, it will have to wait at the tail. It can be used in CRUD statements.
Both ideas are only for the use of table lock effective storage engine, InnoDB should not be used or other engines have the mechanisms and fine-grained concurrent controls. In the MyISAM should be used with caution, because these two tips will lead to concurrent inserts are disabled, can seriously degrade performance.
HIGH_PRIORITY LOW_PRIORITY and in fact simply a queue order to control access to a MySQL data tables.
② DELAYED
This tip is valid for insert and replace. MySSQL will use the prompt statement returns immediately to the client, and the line is inserted into the data buffer, and then writes the data in the batch table is idle. Logging systems using such tips are very effective, or other large amounts of data need to be written but the client does not need to wait for the completion of a single statement I / O applications. This usage has some limitations. Not all storage engines support and the prompt causes the function last_insert_id () does not work.
③ STRAIGHT_JOIN
this tip can be prevented after the select keyword select statement can be prevented between any two names associated table. The first is to make use of all of the tables in the query associated with the order they appear in the statement. The second rule is associated with a fixed sequence before and after the two tables.
When MySQL did not choose the correct order of relevance - or when they order too much because of possible causes MySQL unable to evaluate all of the associated sequence, STRAIGHT_JOIN will be useful in MySQL might issue a lot of time in the state statistics, plus this tip will greatly reduce the optimizer search space
④ SQL_SMALLRESULT and SQL_BIG_RESULT
this prompt is only valid for two select statements. They told optimizer group by or distinct queries on how to use a temporary table and sort. SQL_SMALL_RESULT tell the optimizer that the result is very small rallies the result set can be placed in the temporary memory in the index table to avoid sorting operation. If SQL_BIG_RESULT, will tell the optimizer that the result set can be very large, it is recommended to use a temporary table to do disk sorting operations.
⑤ SQL_BUFFER_RESULT
This hint tells the optimizer to the query results into a temporary table, then quick-release lock the table as possible. This results from the client cache aforementioned different. When you are not using the client cache, the cache using server-side is often very effective. Benefit is without consuming too much memory on the client but also unlock the tables as soon as possible. The cost of the server will require more memory.
⑥ SQL_CACHE and SQL_NO_CACHE
whether this prompt tells MySQL result set should be placed in the query cache.
⑦ SQL_CALC_FOUND_ROWS
Yan brother, this is not a optimizer hints. It does not tell anything about the optimizer execution plan. It will make MySQL returned result set contains more information. MySQL query plus the prompt will calculate the total number of result sets after this clause to limit the query to be returned, but in fact the value returned result set limit requirements. This value can be obtained by a function found_row (). Caution, would later explain why.
⑧ FOR UPDATE LOCK IN SHARE MODE and
this is not true optimizer hints. This prompted two major lock control mechanism of the select statement, but only effective for achieving the row-level locking storage engine. Use the tips will match the query lock rows. For insert / select statement is not required because the two tips of these records will default to the 5.0 plus a read lock.
The only built-in support for these two tips engines is InnoDB, you can disable the default behavior. Also keep in mind that some of these tips will not work properly optimized, for example, an index covering the scan. InnoDB is not exclusive to lock in a row without access to primary keys, because the line of version information stored in the primary key.
If these two tips are often abused, she is easy morning server lock contention.
⑨ USE INDEX, IGNORE INDEX, and FORCE INDEX
these tips will tell the optimizer to use or not use those indexes to query record.
Added some parameters in the 5.0 version to control the optimizer behavior:
① optimizer_search_depth
This parameter controls the optimizer limits in the exhaustive implementation plan. If the query is a long time in state statistics, we can consider lowering this parameter.
② optimizer_prune_level
This parameter is enabled by default, which makes the optimizer will decide whether to skip some of the implementation plan based on the number of lines to be scanned.
③optimizer_switch
This variable contains a number of on / off flag optimizer characteristics.
Used to control the optimizer can take some shortcuts when the first two parameters. These shortcuts can make the optimizer when dealing with a very complex SQL statements can be more efficient, but it may also allow the optimizer to miss some truly optimal execution plan, so caution.
Modify optimizer hints might allow after updating the new version of MySQL optimization strategy fail, so be careful
---------------------
Author: yongqi_wang
Sources: CSDN
text: https : //blog.csdn.net/yongqi_wang/article/details/86527819
Disclaimer: This article is a blogger original article, reproduced, please attach Bowen link! |
|
