1.LIMIT statement
paging query is one of the most frequently used scene, but also usually the most problematic areas. For simple statement such as the following, the general approach is to think of DBA on the type, name, create_time field plus a composite index. Such conditions can be effectively used to sort the index, to elevate performance. Okay, maybe more than 90% of the DBA to resolve the problem so far. But when the LIMIT clause becomes "LIMIT 1000000,10", programmers will still complain: I only get 10 records Why or slow? To know the database does not know the article 1 million records from where to start, even if there is also need to calculate the index from scratch again. This performance problems, in most cases is a lazy programmer. Browse the page data in the front end, or a large batch of data to export other scenes, the maximum value may be as a previous parameter as a query. SQL redesigned as follows:
query time fixed under the new basic design, not with the amount of data grows and changes.
2. implicit conversion
SQL statement query variables and fields defined type mismatch is another common mistake. Statement such as the following: wherein is defined fields bpn varchar (20), MySQL, then the strategy comparison string after converting to digital. Function applied to the table fields, indices failure. The above application framework may be filled automatically parameter rather than the programmer's intent. Now a lot of very complicated application framework, easy to use but also be careful it might give yourself digging.
3. association update, delete
Although MySQL5.6 the introduction of physical and chemical properties, but it currently only requires special attention for optimizing the query statement. For the need to manually update or delete rewritten JOIN. For example, the following UPDATE statement, MySQL is the actual implementation cycles / nested subqueries (DEPENDENT SUBQUERY), the execution time can be imagined. Implementation plan: After rewritten as JOIN, sub-queries into selection mode from DEPENDENT SUBQUERY DERIVED, significantly quicker to perform, down from 7 seconds to 2 milliseconds implementation plan reduces to:
4. Mix ordering
MySQL can not use sort mix index. However, in some scenarios, there are opportunities to use a special method to enhance performance. Execution plan is displayed as a full table scan: Since is_reply only two states 0 and 1, we follow the following method after rewriting, the execution time is reduced from 1.58 seconds to 2 milliseconds.
5.EXISTS statement
When MySQL treat EXISTS clause, the implementation still use nested subqueries. The following SQL statement: execution plan for: removing exists to change the join, can be avoided nested subquery, execution time is reduced from 1.93 seconds to 1 millisecond. The new implementation plan: 6. conditions push down the outer query conditions are not able to view or pushed down to the complex situation subqueries are:
- Aggregation subqueries;
- Containing the subquery LIMIT;
- UNION or UNION ALL subqueries;
- Output fields in the sub-queries;
The following statement, it can be seen from the execution plan which is applied after polymerization conditions subqueries determining query conditions can be directly pushed down semantically rewritten as follows: the execution plan becomes: 7. advance narrow first SQL statement Initial : number of 900,000, time consuming 12 seconds. Since the last WHERE conditions and ordering are for the most left main table, so you can first sort of my_order reduce the amount of data in advance to do a left join. After rewriting the following SQL execution time is reduced to about 1 millisecond. Re-examine the execution plan: after (select_type = DERIVED) subquery materialized participate JOIN. Although the estimated 900,000 still scanning line, but use of the index and LIMIT clause, the actual execution time becomes very small.
8. The intermediate result sets pushdown
Let's look at an example of this has initially been optimized following the (left main table join in the priority action query): So the statement that there are other problems? C is not difficult to see the whole table subqueries aggregate queries, in a particularly large number of table situation will lead to decreased performance of the entire statement. In fact, for subqueries c, left the final outcome of the connection data can be set only interested in the main table and resourceid can match. Therefore, we can rewrite the following statements, execution time decreased from the original 2 milliseconds to 2 seconds.
But a sub-query appears more than once in our SQL statement. Such an approach not only additional costs, but also makes the entire statement of significant complexity. Use the WITH statement rewrite again: 9. summary database compiler to generate an execution plan, determine the actual implementation of SQL. But the compiler just try the service, the compiler of all the databases are not perfect. Most of the above-mentioned scene, there are performance problems in other databases. Learn database compiler features, its weaknesses in order to avoid regulation, to write high-performance SQL statement. In the design of the data model and write SQL statements, thought or consciousness algorithm should be brought in. Write complex SQL statements to develop the habit of using the WITH statement; simple and clear thinking of SQL statements can reduce the burden of database