Teach you how to optimize SQL

Before we start , We need to know ： If my SQL The statement executes fast enough , There is no need to optimize ？

There's no need at all, right

So we generally say , To give SQL Make an optimization , That must be this one SQL The execution of the statement is relatively slow

that , Why is it slow to execute ？

SQL Statement execution is slow 3 One reason

There is no index , Or the index failure leads to SQL Statement execution is slow

This should be easier to understand , If there's a lot of data , Above tens of millions , Then there is no index , Find what you want in these tens of millions of levels of data , It's just hand to hand （ Ouch! , It's amazing , Dare to fight hand to hand

The content of index invalidation is much more , For example, when querying , Give Way like Wildcards are in front , For example, often say “ Left most matching principle ”, Another example is that we use or , and or There is a column without index in the pre and post conditions , And so on, these conditions will lead to index failure

Lock wait

Commonly used storage engines mainly include InnoDB and MyISAM These two , The former supports row locks and table locks , The latter only supports table locks

If all database operations are based on table locks , That is to say , Now there is an update operation , Will lock the whole watch , Then the query operation is not allowed , So let alone improve the concurrency performance of the system

• • 
    
• Smart you must know , since MyISAM Only table locks are supported , So use InnoDB No. It'll be ok ？ Do you think InnoDB Row lock will not be upgraded to table lock ？too young too simple  ！
• If you do a lot of update operations on a table , mysql I think that using it like this will reduce the efficiency of transaction execution , In the end, it will lead to performance degradation , In this case , You might as well upgrade your row lock to a table lock
• And a little bit more , Row lock is a lock based on index , When performing an update operation , The condition index is invalid , Then this lock will also be upgraded from row lock to table lock
  • 
    

Inappropriate SQL sentence

This is also quite common , What is inappropriate SQL Sentence? ？ Like , What you need to find is name , age , But what? , In order to save trouble , direct ​​select *​​, Or in order by when , The latter condition is not an index field , This is inappropriate SQL sentence

Optimize SQL sentence

In the know SQL After the reason for the slow execution of the statement , The next thing to do is to suit the remedy to the case

in the light of No index / Index failure This piece of , The most effective way is to EXPLAIN The grammar , Do you know Show Profile It's ok

in the light of Lock wait This piece of , No way out , Only pay more attention to yourself

in the light of Inappropriate SQL sentence This piece of , Introduce several commonly used SQL Optimize , For example, how to optimize the paging query can make the query faster , You don't mean ​​select *​​ It's not the right way to open ？ Then what is right select The way ？ Don't worry! , Ah fan will talk about it next

I don't say much nonsense , Let's start

Let's start with a watch

To ensure that the optimized results are the same as what I wrote （ At least, 90% It's consistent

So shall we use the same database ？ Obedient ~

First, build one demo The database of

Next, let's build a table , Just build a very simple table, okay

Log in and copy

       

        CREATE TABLE demo.table(
        
 id int(11) NOT NULL,
        
 a int(11) DEFAULT NULL,
        
 b int(11) DEFAULT NULL,
        
 PRIMARY KEY(id)
        
) ENGINE = INNODB
       
       

        
1.
        
2.
        
3.
        
4.
        
5.
        
6.
       

Then insert 10 Ten thousand data

Log in and copy

       

        DROP PROCEDURE IF EXISTS demo_insert;
        
CREATE PROCEDURE demo_insert()
        
BEGIN
        
    DECLARE i INT; 
        
  SET i = 1;
        
    WHILE i 
        <
        = 
        100000 
        DO
        

        INSERT 
        INTO 
        demo.`table` 
        VALUES 
        (i, 
        i, 
        i);
        

        SET 
        i = 
        i 
        + 
        1 
        ;
        

        END 
        WHILE;
        

        END;
        

        CALL 
        demo_insert();
       
       

        
1.
        
2.
        
3.
        
4.
        
5.
        
6.
        
7.
        
8.
        
9.
        
10.
        
11.
       

OK , The preparations are ready , Next, we will start the actual battle

adopt EXPLAIN analysis SQL How is it carried out

Just say SQL tuning , Then we can't do without EXPLAIN

​​EXPLAIN SELECT * FROM​​​table​​WHERE id < 100 ORDER BY a;​​

We can see that there are several parameters :

• id : Every execution plan will have one id , If it is a joint query , There will be many id
• select_type : It means select Query type , Common is SIMPLE ( Common query , That is, there is no joint query / Subquery ), PRIMARY ( Main query ), UNION ( UNION The following query in ), SUBQUERY ( Subquery )
• table : Execute the table of the query plan , What I check here is table , So what's shown is table, So if I give table It's a nickname a , What is shown here is a
• type : How the query is executed , This is what we are analyzing SQL A very important indicator when optimizing , This value is in order from good to bad : system > const > eq_ref > ref > range > index > ALL

• • 
    
• system/const : Note that only one row of data in the table matches , At this time, the corresponding data can be found by querying the index once
• eq_ref : Scan with unique index , This is often in the multi table connection , When using primary key and unique index as association conditions, you can see
• ref : Non unique index scan , You can also see in the leftmost principle matching scan of the unique index
• range : Index range scan , For example, the query conditions are used < , > , between Equal conditions
• index : Index full table scan , At this time, the entire index tree will be traversed
• ALL : Indicates full table scan , That is, you need to traverse the whole table to find the corresponding row
  • 
    

• possible_keys : Indicates the index that may be used
• key : Index actually used
• key_len : Index length used
• ref : relation id Etc
• rows : Find the qualified , Number of rows scanned , Although there are 10 Ten thousand data , But because of the index , So I scanned 99 Row data
• Extra : Additional information , The common ones are the following
  • 
    

• Using where : Don't read all the information in the table , You can get the required data only by indexing , This process occurs when all the request columns of the table are the same index part

• Using temporary : Express mysql You need to use temporary tables to store result sets , Common in group by / order by

• Using filesort : When the query statement contains order by During operation , and order by The following content is not an index , In this way, there is no way to use the index to complete sorting , Will use " File sorting ", As the example shows , The index established is id , But my query statement order by And then a , There is no way to use indexes

• Using join buffer : Connection caching is used

• Using index : Override index used

  • 
    

If you know these parameters very well , that EXPLAIN This content can't help you

Show Profile Under the analysis of SQL Executive performance

adopt EXPLAIN Analysis execution plan , That means SQL External implementation of , If you want to know mysql How to query , Need to pass through Show Profile To analyze

Can pass ​​SHOW PROFILES;​​ Statement to query the most recently sent to the server SQL sentence , By default, it records the recently executed 15 Bar record , As shown in the figure below, we can see :

I want to see a specific sentence , notice Query_ID Yes ？ Then run ​​SHOW PROFILE FOR QUERY 82;​​ This order will do :

You can see , In the result , Sending data It takes the longest , And that's because right now mysql The thread starts reading data and returning it to the client , In this process, there will be a large number of disks I/O operation

Through this analysis , We can know , SQL Statement during query , What is the disk I/O Affect the query speed , still System lock Affect the query speed , Know the disease , Next, it's much easier to prescribe the right medicine

How can paging queries be faster

When using paged queries , Will use limit keyword

But for paged queries , In fact, it can also be optimized

The database I give here is not very good , Because it's so simple , I can't see the difference , I use the table currently used in the project to do an experiment , You can see the difference （ The use of SQL The statement is as follows ）:

Log in and copy

       

        EXPLAIN SELECT * FROM `te_paper_record` ORDER BY id LIMIT 10000, 20;
        

        
EXPLAIN SELECT * FROM `te_paper_record` WHERE id >= ( SELECT id FROM `te_paper_record` ORDER BY id LIMIT 10000, 1) LIMIT 20;
       
       

        
1.
        
2.
        
3.
       

The picture above , I didn't use subqueries , You can see the execution 0.033s , The following query statement , I used subqueries to optimize , You can see the execution 0.007s , The result of optimization is still obvious

that , Why is subquery used , The speed of query is raised , This is because when we do not use subqueries , Query to the 10020 The row data is returned , Next, we have to deal with this 10020 Then filter the row data

Can you directly return what you need 20 What about row data , In this way, there is no need to filter , Just return directly

You are too clever . Subquery is doing this

Therefore, the query time has been greatly optimized

Correct select Open mode

In the query , Sometimes for the sake of ease , Use it directly ​​select * from table where id = 1​​ In this way SQL sentence , However, such a writing method will have a certain performance loss in some environments

So the best select The query is , You can query any field you need

Generally, when querying , There will be conditions , Search by criteria

This is the right time select What is the opening method ？

If you can index by primary key , where Later conditions , Primary key index is preferred

Why? ？ This is to know MySQL Storage rules for

MySQL Common storage engines are MyISAM and InnoDB , InnoDB Will create a primary key index , The primary key index belongs to cluster index , That is, when storing data , It's based on the index B+ Composed of trees , The specific row data is stored in the leaf node

in other words , If it is queried through the primary key index , Will search directly B+ Trees , So as to query the data

If it is not queried through the primary key index , You need to search the index tree first , Get in B+ The value on the tree , Until then B+ Search the tree for qualified data , This process is “ Back to the table ”

Obviously , Back to the table can generate time .

That's why I suggest , where Later conditions , Primary key index is preferred

Other tuning

After reading the above , I should probably know it in my heart , SQL Tuning is mainly about indexing / Prevent lock waiting / Use appropriate SQL Statement to query

however , If I ask you, in addition to the index , In addition to the above means , Are there any other tuning methods

what ？ There is even ？！

yes , we have , This requires jumping out , Don't limit yourself to specific SQL The sentence is on , It needs to be considered at the beginning of database design

for instance , We often say that we should follow three paradigms , But in some business scenarios , If there are several redundant fields in the database , It may be much better than the performance brought by strictly following the three paradigms .

But this is the accumulation of the test at ordinary times , After ah fan raised this point here , I hope readers can see if there are any redundant fields in the database currently used in their project , Why is it designed like this ？ So much observation , It's difficult for you to improve your technical ability

above , That's it ~

< END >

If you like our article , Welcome to forward , Click "watch" to let more people see .