Mysql performance optimization

Mysql performance optimization

Performance optimization dimension

Database optimization ideas

The idea of emergency optimization ：

Dealing with sudden business , Normal business processing is not possible ！ Scenes that need to be solved immediately ！

1. show processlist（ View connections session state ）

2. explain( Analyze the query plan ),show index from tableName（ Analysis index ）

3. show status like ‘%lock%’; # Query lock status

Conventional tuning ideas ：

Caton for business cycle , For example, every day 10-11 Point business is particularly slow , But it can also be used , It will be good after this time .

1. Turn on Slow query log , Run for one day
2. see slowlog, analysis slowlog, Analyze the statement with slow query .
3. According to certain priority , Check all slow statements one by one .
4. analysis top sql, Conduct explain debugging , View statement execution time .
5. Adjust the index or statement itself .

## Optimization Practice

Query optimization

see sql Statement execution plan Explain
effect

1. View the read order of the table
2. Check the operation type of database read operation
3. See which indexes might be used
4. See which indexes are actually used
5. View references between tables
6. See how many row records in the table are queried by the optimizer

Data preparation

create table t1(
  id int primary key,
  name varchar(20),
  col1 varchar(20),
  col2 varchar(20),
  col3 varchar(20)
);

create table t2(
  id int primary key,
  name varchar(20),
  col1 varchar(20),
  col2 varchar(20),
  col3 varchar(20)
);

create table t3(
  id int primary key,
  name varchar(20),
  col1 varchar(20),
  col2 varchar(20),
  col3 varchar(20)
);

insert into t1 values(1,'zs1','col1','col2','col3');
insert into t2 values(1,'zs2','col2','col2','col3');
insert into t3 values(1,'zs3','col3','col2','col3');

create index ind_t1_c1 on t1(col1);
create index ind_t2_c1 on t2(col1);
create index ind_t3_c1 on t3(col1);

create index ind_t1_c12 on t1(col1,col2);
create index ind_t2_c12 on t2(col1,col2);
create index ind_t3_c12 on t3(col1,col2);

View execution plan

EXPLAIN SELECT * FROM t1;

Type full table scan （ Low efficiency ）

type:
type It shows the type of access , Is a more important indicator , The result value from the best to the worst is

system > const > eq_ref > ref > fulltext > ref_or_null > index_merge > unique_subquery > index_subquery > range( Try to make sure that ) > index > ALL

system： surface ( The system tables ) There is only one line of record in the , This is a const Special case of type , Basically not

const： It's found by index once ,const For comparison primary key perhaps unique Indexes , The table has at most one matching row , Read at the beginning of the query . Because there is only one line , Therefore, the values of the columns in this row can be treated as constants by the rest of the optimizer .const The watch is very fast , Because they only read once .

explain select * from t1 where id=1

eq_ref： Read a row composed of each row in this table and the associated table . except 了 system and const Out of type , This is the best connection type . When the connection uses all parts of the index , An index is a primary key or unique non - NULL When indexing , This value will be used .

explain select * from t1,t2 where t1.id = t2.id;	

ref： Non unique index scan , Returns all rows that match a single value , In essence, it is also an index access , It returns all eligible rows .

explain select * from t1 where col1='zs1';

range: Retrieve only rows in the given range , Use an index to select rows .key Column shows which index is actually used , It's usually in where Use in condition between,>,<,in Conditions of equal scope , This index range scan is better than a full table scan , Because it only scans in a certain range , You don't need to scan all indexes

explain select * from t1 where id between 1 and 10;

index: Scan the entire index table , index and all The difference is index Type only traverses the index tree . This is usually better than all fast , Because index files are usually smaller than data files , although index and all Read the whole watch , however index Read from index , and all It's reading data from the hard disk

explain select id from t1;

all: Full table scan , Will traverse the entire table to find the matching rows

explain select * from t1;

select_type

- SIMPLE :  ordinary select Inquire about , The query does not contain subqueries or UNION

- PRIMARY:  If the query contains complex subqueries , The outermost query is marked PRIMARY

- SUBQUERY :  stay SELECT perhaps WHERE The list contains subqueries 

- DERIVED :  stay from The list contains subqueries marked with DRIVED derivative ,MYSQL These subqueries will be executed recursively , Put the results in a temporary table 

- UNION:  If the second SELECT Appear in the union after , Is marked as UNION,  if union Included in from Clause , Outer layer select Marked as :derived

- UNION RESULT:  from union Table to get the result select

Index optimization

Common index categories

• General index
• unique index
• primary key
• Composite index
• Full-text index

Index storage structure

BTree Indexes

​ In the previous example, we see that there are USING BTREE, What is this ？ This is MySQL The indexing scheme used ,MySQL Medium common use B+Tree Do the index , That is to say BTREE.

Why use B+ Trees ：

​ B+ The tree is a Multiway balanced search tree , It and B The main difference between trees is :

• B Every node in the tree （ Leaf nodes and non leaf nodes ） All store real data . and B+ Leaf nodes like trees store values , Non leaf nodes store keys .
• B A record in the tree will only appear once , There will be no repetition . and B+ The key of the tree may be duplicated .
• B+ The leaf nodes of the tree are connected by a two-way linked list .

​ Based on the above characteristics ,B+ Trees have the following advantages ：

• Less IO frequency ：B+ The non leaf node of the tree contains only keys , Not real data , So the ratio of the number of records stored in each node B Count a lot （ Immediate order m Bigger ）, therefore B+ The height of the tree is lower , What you need to visit IO Fewer times . Besides , Because each node stores more records , So the use of access locality principle is better , Higher cache hit rate .
• More suitable for range queries ： stay B When range query is performed in the tree , First find the lower bound to find , Then on B The tree is traversed in the middle order , Until you find the upper limit ; and B+ Tree range query , Only need to List traversal that will do .
  -** More stable query efficiency ：**B The query time complexity of the tree is 1 To the height of the tree ( They are recorded in the root node and the leaf node respectively ), and B+ The query complexity of tree is stable to tree height , Because all the data is in the leaf node .

however B+ Trees also have their own shortcomings , Because the key may be repeated , So it takes up more space . But for modern servers to compare performance , Spatial disadvantages are basically acceptable .

Hash index

​ Hash Index in MySQL Not a lot of , Right now it's mainly Memory Storage engine use , stay Memory In the storage engine Hash Index as the default index type . So-called Hash Indexes , In fact, through a certain Hash Algorithm , Will need to index the key value Hash operation , And then you'll get Hash Value is put into a Hash In the table . And then every time you need to retrieve , All of them will perform the same algorithm for the retrieval conditions Hash operation , And then with Hash In the table Hash The values are compared and the corresponding information is obtained .

characteristic ：

• Hash Index can only satisfy “=”,“IN” and “<=>” Inquire about , Can't use range query ;
• Hash Indexes cannot be used to avoid data sorting operations ;
• Hash Index can't query with partial key ;
• Hash Index can't avoid table scanning at any time ;
• Hash Index encountered a lot of Hash When the values are equal, the performance is not necessarily better than B+Tree High index ;

Index failure

Data preparation

CREATE TABLE staffs (
  id INT PRIMARY KEY AUTO_INCREMENT,
  name VARCHAR (24)  NULL DEFAULT '' COMMENT ' full name ',
  age INT NOT NULL DEFAULT 0 COMMENT ' Age ',
  pos VARCHAR (20) NOT NULL DEFAULT '' COMMENT ' Position ',
  add_time TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT ' Entry time '
) CHARSET utf8 COMMENT ' Employee record form ' ;
 

INSERT INTO staffs(name,age,pos,add_time) VALUES('zhangsan',18,'manager',NOW());
INSERT INTO staffs(name,age,pos,add_time) VALUES('lisi',19,'dev',NOW());
INSERT INTO staffs(name,age,pos,add_time) VALUES('wangwu',20,'dev',NOW());

SELECT * FROM staffs;

ALTER TABLE staffs ADD INDEX idx_staffs_nameAgePos(name, age, pos);

• Full match ( Indexes idx_staffs_nameAgePos Index with name,age,pos The order of the establishment of . A full value match indicates Matching in order

EXPLAIN SELECT * FROM staffs WHERE name = 'July';
EXPLAIN SELECT * FROM staffs WHERE name = 'July' AND age = 25;
EXPLAIN SELECT * FROM staffs WHERE age = 25 AND name = 'July' AND pos = 'dev';

EXPLAIN SELECT * FROM staffs WHERE age = 25;  
EXPLAIN SELECT add_time FROM staffs WHERE age = 25 AND pos = 'dev'; 

• The leftmost prefix rule ( If you index multiple columns , Observe The leftmost prefix rule . It means that the query starts from the left front of the index and does not skip the columns in the index .)

-- 【 Be careful 】
-- and  Ignore the left-right relationship . Even if not in order   Because of the optimizer , Will automatically optimize .
--  Apart from the above conditions   To satisfy the leftmost prefix rule .
EXPLAIN SELECT * FROM staffs WHERE age = 25 AND pos = 'dev'; --  Index failure  
EXPLAIN SELECT * FROM staffs WHERE pos = 'dev';--  Index failure 

• Do nothing on the index column （ Calculation 、 function 、( Automatically or Manual ) Type conversion ）, If you do , Will cause the index to fail and turn Full table scan

EXPLAIN SELECT * FROM staffs WHERE left(name,4) = 'July';

• The storage engine cannot use the range condition in the index (between、<、>、in etc. ) The column on the right ( The right side of the range condition is the same composite index used by the range condition , The one on the right will fail . If the index is different, it will not be invalid ).

EXPLAIN SELECT * FROM staffs WHERE  name = 'July' AND age > 25 AND pos = 'dev';

• Reduce select *, Which fields are used to check which fields .

• mysql5.7 In use is not equal to (!= perhaps <>) Unable to use the index will result in a full table scan . but 8.0 Can't .

• mysql5.7 is not null You can't use indexes , however is null Index can be used . but 8.0 Can't

• like With % start (’%abc…’)mysql Index invalidation will become a full table scan operation

• String index is invalid without single quotation marks ( The underlying conversion invalidates the index , Using a function causes the index to fail )（ Implicit type conversion ）