sql optimization finishing (a)

  Write sql syntax is this:

SELECT DISTINCT 
	<select_list>
FROM 
	<left_table> <join_type> 
JOIN <right_table>	ON <join_condition>
WHERE 
	<where_condition>
GROUP BY 
	<group_by_list>	
HAVING 
	<having_condition>
ORDER BY 
	<order_by_condition>
LIMIT <limit_condition>

  

  MySQL sequential read like this:

FROM <left_table>
ON <join_condition>
<join_type> JOIN <right_table>
WHERE <where_condition>
GROUP BY <group_by_list>
HAVING <having_condition>
SELECT
DISTINCT <select_list>
ORDER BY <order_by_condition>
LIMIT <limit_condition>

  

  

  MySQL official definition of the index: the index is to help MySQL efficiently get the data structure of the data; an index is to improve query efficiency, similar to the dictionary; rows of data structures quickly find a good sequence; the index will affect the wherequeries and behind the order bysort behind ; general index itself is also great, it can not all be stored in memory, so the index tend to storage in the form of index files on disk; frequent additions and deletions to the table does not build the index;

 

  Index Advantage:

    Improve the efficiency of data retrieval, reducing the cost of IO database; indexes the indexed columns data, cost data sorting, reducing consumption of the CPU;

  Index disadvantages:

    In fact, the index is also a table that holds the primary key and index fields, and points to record a solid table, so the index column is to take up space; While the index greatly increased query speed, but will reduce the speed of updating the table, such as the table INSERT, uPDATE, and DELETE; because when you update table, MySQL is not only to save the data, but also to save the index file to update the index every column fields added, will adjust because the index information after key changes brought about by the update;

  

  The case for indexing:

1. The primary key automatically create unique index 
2. frequent as the query condition field should be indexed 
3. Query table associated with other fields, foreign key relationship index 
4. frequently updated index field is not suitable, because not only each update It is to update the record also updates the index structure; 
less than the conditions in the field 5.where not create an index 
6. queries sort field, sort field if I go through the index will greatly enhance the access speed sorting 
7. queries or packet statistics fields

  

  The situation is not suitable for creating an index:

1. The table records too little is not suitable for indexing; 
2. Regular additions and deletions to the index table does not fit; improve query speed, while it will update the table speed, as the table insert operation, because when you update table, MySQL is not only to save the data, but also save the table index structure; 
3. data repeatable and uniform distribution of the field in the table is not suitable for indexing, and therefore should only be indexed and sorted data most often the most frequently queried; Note that if a data column contains duplicate content, index it is established there is no much effect;

  

 

  MySQL performance bottlenecks common:

1.CPU: CPU when saturation typically occurs when data is loaded into memory or reading data from the disk when 
2.IO: disk I / O bottlenecks occur in loading the data memory is much larger than the time 
3. server hardware performance bottlenecks: top, free, iostat and vmstat to check system performance status

  

  Use EXPLAIN:

Reading order table 1. 
2. Data reading operation of the operation type 
3 which indexes can be used 
4 which indexes are actually used 
references between 5. Table 
6. Each table row number of the query optimizer is

  

  EXPLAIN field explanation:

    • id: SEQ ID NO select query, contains a set of numbers indicating the order of clauses or select a query execution operation table

      three situations:

      • id the same, the order from top to bottom;
      • Different id, if the query is a child, id serial number is incremented, the greater will be the higher priority id value, the first execution
      • Unlike different id, exist; id if the same, may be considered as a group, performed from the top down;, id value is larger in all groups, the higher the priority, the first implementation; derived derived, is a temporary table , followed by the numbers corresponding to respective ID;

 

    • Complex queries query type, mainly used to distinguish normal query, the join, as subqueries, etc. (SIMPLE, PRIMARY, SUBQUERY, DERIVED, UNION, UNION RESULT);: select_type
      • SIMPLE: simple select query, the query does not contain subqueries or UNION
      • PRIMARY: If the query contains any complex subqueries, the outermost query is labeled PRIMARY
      • SUBQUERY: contains a subquery in the SELECT list or WHERE
      • DERIVED: FROM subquery included in the list are marked as DERIVED (derivative), MySQL recursively executing the sub-queries, the results into temporary table;
      • UNION: If after the second SELECT appears UNION, UNION is labeled; if the query contained in the sub UNION FROM clause, the outer layer will be marked as SELECT DERIVED;
      • UNION RESULT: The UNION operation, id value is usually NULL

 

    • table: to display data in this line of tables on which

 

    • type: Displays the query uses what type,

      From best to worst are:

        system>const>eq_ref>fulltext>ref_or_null>index_merge>unique_subquery>index_subquery>range>index>ALL

         system>const>eq_ref>ref>range>index>ALL

      • system: the table has only one row (equal to the system table), which is a special type const column, usually does not occur, this may be negligible

      • const: represented by the index once found, const for comparing primary key or unique index, because the only matches one row of data, so quickly; if the place where the primary key list, MySQL will be able to convert the query to a constant

      • eq_ref: unique index scan, for each index key, the table is only one matching record; unique or common to the primary key indexes;

      • ref: non-uniqueness microcosm scan returns all rows matching a single value; in essence is a kind of index access, which returns all rows that match a single value, however, may find it more in line with the conditions of the line, so it should belong to a mixture of search and scanning;

      • range: retrieve only to the line given range, using an index to select the rows, key column shows which index is used; in general there was an in between where statement, <,>, in such inquiry; this ratio index range scan full table scan is better, because it only needs to start at some point in the index, ended at a certain point, you do not have to scan the entire index;

      • index: index differs only ALL is traversing the index tree index type; this is usually faster than ALL, because the index file is typically smaller than the data files (all are read and the entire table index, but the index is read from the index, and all read out from the hard disk)

      • all: will traverse the whole table to find matching rows

 

    • possible_keys: this shows the possible application in the index table, one or more query fields related to the presence, if the index, the index will be listed, but not necessarily actually used by the query;

 

    • key: the index actually used; if it is NULL, then do not use indexes; if the query using a covering index, the index appears only key list;

 

 

    • key_len: number of bytes used in the index, the index can be used in the query length is calculated by the column; without loss of accuracy, a length as short as possible; the maximum possible length values ​​of the index fields displayed key_len, not actual length, i.e., is calculated on the basis key_len table definition, are not retrieved by the table;

 

    • ref: Display index which column is used, which columns or constants are used to find the index value, where const is a constant;

 

    • rows: The selection of the index table statistics and case, a rough estimate of the number of lines required for recording to be read

 

    • extra: unsuitable for display shown in the other columns, but additional information is very important
      • using filesort: mysql will be described using an external data ordering index, rather than reading the table sorted by index; mysql can not be done using the index file referred to sort the sort operation;

      • using temporary: the temporary table using intermediate results, mysql temporary table used when sorting query results, commonly used in order by sorting and grouping query group by

      • using index: represented by a corresponding select operation using a covering index, to avoid data access table rows; using where if there is the same time, the index indicates that the key is used to perform a lookup index; if not present at the same time using where, for index showed to read the data rather than performing a lookup operation;

        Way of understanding covering indexes:

          1.select columns of data can be obtained only from the index column, without reading the data row, MySQL can use an index to return the select list of fields, without having to read the data file again according to the index; query column to be built index covering

          2. The index is a highly efficient method to find the line, but generally the database data can be used to find the index of a column, it is not necessary to read the entire line; after their index leaf node stores the index data read by the index when it is can be thought of data, it does not need to read the line, contains an index (or covering) satisfy the query results data is called a covering index

          Note: If you are using a covering index, must pay attention to remove only the select list columns need not select *, if indexed together all fields will cause the index file is too large, the query performance degradation;

      • using where: that the use of filters where

      • using join buffer: use the connection cache

        JOIN statement is guaranteed on the driving conditions JOIN table index field has been added;

         

        • When a left join, the drive table is left table, the table being driven right table

        • When a right join, the drive tables right table, the table is left driven table

        • When a join, mysql will choose a smaller amount of data table as the driving table, the table is driven as a large table

      • impossible where: where clause is always false, can not be used to obtain any tuple

      • select tables optimized away: in the case where no group by clause, based on the index optimization MIN / MAX operation MyISAM storage engine or optimization for COUNT (*) operation, without waiting for the execution phase and then calculated, cha'x execution plan generation stage complete optimization;

      • distinct: optimization distinct, stop looking for work at the same value found after the first matching tuple

 

Guess you like

Origin www.cnblogs.com/coder-zyc/p/11718449.html