Storage structure index
l B Tree and B + Tree Characteristics and differences
* Height of the tree are generally in the 2-4 this height, directly affect the height of the tree the number of IO read and write.
* If there are three tree --- supporting data may reach 20G, if the tree structure --- four supporting data may reach tens T
* B Tree and B + Tree biggest difference is that the question of whether to store data non-leaf nodes. B Tree non-leaf nodes and the leaf nodes are stored data. And B + Tree leaf nodes will only store data, and the data are stored on a single line, and these are all the data pointer, i.e. the sequence.
l non-clustered index
* Pointer to the leaf nodes only store the data lines , in short, the data and indexes are not together, that is, non-clustered index.
* Primary key index and a secondary index pointer values are stored
l clustered index ( the InnoDB)
* Primary key index (clustered index) of the leaf node stores the data lines, that is to say the data and indexes are together, this is the clustered index.
* Secondary indexes will only store the primary key value
* If there is no primary key , use the unique index build clustered index; if there is no unique index, MySQL will create a clustered index according to certain rules.
Note the use of the index
l try to create a composite index (composite index will actually default according to the most left-prefix principles to help us to create groups of indexes)
Combination index ( ID, name, Sex)
The most left-prefix principle l index
l index covering: the column to query, but also covers the use of the index
MySQL Performance of view an execution plan explain
Introduction
l MySQL provides an EXPLAIN command , it can be to analyze the SELECT statement , and output details SELECT executed for developers targeted optimization.
l Use explain this command to view an execution plan these SQL statements, see the SQL statement has no use on the index, have not done a full table scan, which can be viewed by explain command.
l can explain MySQL command-depth understanding of cost-based optimizer, you can also get a lot of details may be optimized access policy is taken into account, as well as when running SQL statements which strategy is expected to be adopted optimizer.
l EXPLAIN command usage is very simple, plus explain before the SELECT statement can be, for example:
explain select * from user
Parameter Description
expain have 10 out of the information, namely, ID , SELECT_TYPE , Table , type , The possible_keys , Key , The key_len , REF , rows , Extra , These fields are explained below:
l id:. identifier of each SELECT SELECT query is automatically assigned a unique identifier.
L SELECT_TYPE : SELECT type queries.
l table: Which table query
l partitions: Partition match
L of the type : the Join Type
l possible_keys: The query may be selected index
L Key : The exact use to query the index.
L REF : constant or which field is used together with key
L rows : This query displays the total number of scanning lines this is an estimate.
l filtered: This indicates the percentage of the filtered query data
l extra: additional information
select_type Column Description
L SIMPLE , indicates that this query does not contain query or sub-query UNION
L PRIMARY , indicating a query is the outermost query
L UNION , indicating a query is a second or subsequent queries of a UNION
l DEPENDENT UNION, the second or later UNION queries, depending on the outside of the query
l UNION RESULT, UNION results
L SUBQUERY , the first sub-query SELECT
L DEPENDENT SUBQUERY :. first subquery SELECT, depending on the outside of the query is dependent on the results of the subquery outer query.
1.1 of the type Column Description
Generally speaking , the different types of performance type relationship is as follows:
ALL <index <~ index_merge Range <REF <eq_ref <const <System
| Types of |
meaning |
| system |
Table only one row |
| const |
Table match at most one row, generic or unique primary key index when compared |
| eq_ref |
Each time, only read the table combined with the previous row of the table row, which is in addition to the system, const best kind, characterized by the use =, and all are involved in the join parts of the index and the index is a primary key or empty unique key index |
| ref |
If a time match a small number of rows, it is better kind, or = <=> use, may be left covered or non-primary key index or a unique key |
| fulltext |
research all |
| ref_or_null |
Similar to the ref, but including NULL |
| index_merge |
It indicates that an index merge optimization (including the intersection, union and intersection between the union), but does not include cross tables and full-text indexing. This complex, combined current understanding is single-table index scan range (if the cost estimate to be better than normal range, then |
| unique_subquery |
In the in the sub-query is value in (select ...) to the form "select unique_key_column" subqueries replacement. PS: So not necessarily in sub-clause of the query is inefficient! |
| index_subquery |
As above, but shaped like a son to "select non_unique_key_column" query replace |
| range |
Constant value range |
| index |
. A cover when the query is indexed, i.e., all the available data (Extra has Using Index) from the acquired time index tree; . B index order to find a full table scan line data (no Using Index) from the index; . C If the Extra Using Index and the simultaneous Using Where, then, is to use the index to find key means; d. If appear alone, it is read by the read index to replace the line, but not for finding |
| all |
Full table scan |
Performance optimization of MySQL slow query
Performance optimization ideas
1. First need to use slow queries, all queries to acquire a longer period of SQL query language
2. Use SQL explain to view the execution plan.
3. Use show profile to see performance issues when the SQL execution.
Introduction
l database query speed is a major factor affecting the performance of the project, for the database, we not only to optimize SQL, more importantly, must first find the need to optimize SQL .
l MySQL database has a " slow query log " function is used to record the query time exceeds a set value of SQL , which will greatly help us to quickly navigate to the crux of the matter , in order to prescribe the right medicine.
* As for how much time a query is considered slow, each item of business has different requirements.
* Traditional enterprise software allows query time above a certain value, but this standard on the Internet or on Sheremetyevo project site, it is estimated that a bug, and may even be upgraded to a functional defect.
l MySQL slow query log function is off by default, need to manually open .
Turn on slow query function
l Check whether to open slow query function
show variables like '%slow_ query% ' ;
SHOW VARIABLES LIKE" long query ti me%
Parameters :
* Slow_query_log : whether to open the slow query log, ON to ON, OFF is off, you can turn if off.
* Log-slow-queries: Legacy (version 5.6 or less) MySQL database slow query log storage path. Can not set this parameter, the system will default to a default file host_name-slow.log
* SLOW-Query-log-File : the new version ( 5.6 or later) MySQL database slow query log storage path. Can not set this parameter, the system will default to a default file host_name-slow.log
* Long_query_time : slow query threshold, when the query time is more than a set threshold, logging seconds.
l temporary turn on slow query function
In MySQL execute SQL statements set, but if the restart, then MySQL will fail
set global slow_query_log = ON;
set global long_query_time = 1;
l 永久开启慢查询功能
修改/etc/my.cnf配置文件，重启 MySQL, 这种永久生效.
1 [mysqld] 2 slow_query_log = ON 3 slow_query_log_file = /var/log/mysql/slow.log 4 long_query_time = 1
l 慢日志格式
格式说明：
* 第一行,SQL查询执行的时间
* 第二行,执行SQL查询的连接信息，用户和连接IP
* 第三行,记录了一些我们比较有用的信息，如下解析
Query_time,这条SQL执行的时间,越长则越慢
Lock_time,在MySQL服务器阶段(不是在存储引擎阶段)等待表锁时间
Rows_sent,查询返回的行数
Rows_examined,查询检查的行数，越长就当然越费时间
* 第四行,设置时间戳，没有实际意义，只是和第一行对应执行时间。
* 第五行及后面所有行（第二个# Time:之前）,执行的sql语句记录信息，因为sql可能会很长。