Sometimes only one line of statements are queried, and the execution is slow

Sometimes only one line of statements is queried , Slow implementation

1 Query does not return... For a long time

• If there is one SQL

  mysql> select * from t where id=1;
  

  • The query result will not be returned for a long time

    

  • It's usually a watch t Locked in , Execute at this time show processlist

1.1 etc. MDL lock

• Use show processlist Command view Waiting for table metadata lock Schematic diagram .

  

  • This state indicates , Now there is a thread working on the table t To request or hold MDL Write lock , hold select Blocked
  • Inquire about sys.schema_table_lock_waits This table , Find the blocked process id, use kill Command will disconnect
  • 

1.2 etc. flush

• perform SQL

  select * from information_schema.processlist where id=1;
  

  • Find out that the status of this thread is Waiting for table flush, You can imagine why .

  • 

  • This state represents , Now another thread is about to heap the table t do flush operation ,MySQL There are tables piled inside flush Usage of operation , There are generally the following two :

    
    flush tables t with read lock;
    
    flush tables with read lock;
    
    //flush tables  Yes, it will buffer pool Data is brushed back to disk 
    

  • these two items. flush sentence , If you specify a table t Words , On behalf of just closing the watch t; If no specific indication is specified , It means off MySQL All the open watches in .

    • Normally, this statement executes very quickly , Unless it is also blocked .
    • therefore , appear Waiting for table flush The possible state is ： There is one flush tables The command is blocked by another statement , Then it blocked our select sentence .

• Repeat step

  

  1. stay session A in , Call once per line sleep(1), In this way, this statement is executed by default 10 Thousands of seconds , In the meantime, watch t Has been session A open .

  2. show processlist

  3. take sessionA Threads kill 13

     KILL [CONNECTION | QUERY] processlist_id
      kill query 13 // The connection is SQL Execution will continue 
      kill 13 // With or without , Will kill the thread .
     

1.3 Wait for the line lock

• SQL

   select * from t where id=1 lock in share mode; 
   
    select k from t where id=1 lock in share mode; 
    select k from t where id=1 for update; 
    select  If the statement is locked , It's the current reading ;
     Read locks are added respectively （S  lock , Shared lock ） And write lock （X  lock , Exclusive lock ）.
  

  • because id = 1 This record is read locked , If there is already a transaction holding a read lock on this row of records , our select The statement will be locked .

  • 

  • Query statements are locked ：

  • So it is session A Start transaction , After occupying the write lock , No submission yet , Led to session B Locked up .

  • Query occupancy

    select * from t sys.innodb_lock_waits where locked_table='`test`.`t`'\G
    

  • And then query kill fall , It needs to be done directly kill id , Disconnect the connection directly , The transaction rollback will release the lock .

2 Slow query

•  select * from t where c=50000 limit 1;
  

• Due to fields c There is no index on , So this sentence goes straight id primary key , Perform a full table scan .

  • There are many scanning lines , Slow execution . Bad queries are not necessarily slow queries

• diselect * from t where id=1;
  select * from t where id=1 lock in share mode;
  

  • The first sentence is slow query ：

  • The second sentence is slow query ：

    [ Failed to transfer the external chain picture , The origin station may have anti-theft chain mechanism , It is suggested to save the pictures and upload them directly (img-b9UYTdjJ-1656643464196)(https://cdn.jsdelivr.net/gh/Cltlient/PiGoCDN/img/20220113171449.png)]

  • Execution results ：

    

• Repeat step ：

  • session A First use start transaction with consistent snapshot The command starts a transaction , after session B Just started to execute update sentence .、
  • session B Executive ten thousand 100 Ten thousand times update after ,id = 1 The status of this line is as follows ：[ Failed to transfer the external chain picture , The origin station may have anti-theft chain mechanism , It is suggested to save the pictures and upload them directly (img-P5g5ZU38-1656643464197)(https://cdn.jsdelivr.net/gh/Cltlient/PiGoCDN/img/20220113171702.png)]
  • session B Update complete 100 Ten thousand times , Generated 100 10000 rollback logs (undo log).
  • belt lock in share mode Of SQL sentence , It's the current reading , So you will read directly 100001 This result , So it's very fast ;
  • select * from where id =1 This statement , It's consistent reading , So we need to 100001 Start , One time execution undolog, perform 100 Ten thousand times , take 1 This demerit is returned .

3 Summary ：

• One line short ： Possible examples of locking and slow execution , Mainly watch lock 、 The concepts of row locking and consistent reading .

• problem ：

  • For example, when locking reading , Use this statement ,select * from t where id=1 lock in share mode. because id There's an index on , So you can directly locate id=1 This business , Therefore, read lock is only added to this line .

  • But if it's the following SQL sentence ,

    
    begin;
    select * from t where c=5 for update;
    commit;
    

  • How to lock this statement ？ When is the lock added released ？