19 | 为什么我只查一行的语句，也执行这么慢？

第一类：查询长时间不返回

  大概率是表被锁住了。一般都是首先执行一下show processlist命令，看看当前语句处于什么状态。

等MDL锁

  show processlist命令，显示Waiting for table metadata lock。表示现在有一个线程正在表t上请求或者持有MDL写锁，把select语句堵住了。
  通过查询sys.schema_table_lock_waits这张表，我们就可以直接找出造成阻塞的process id，把这个连接用kill 命令断开即可。

等flush

  线程的状态是Waiting for table flush

等行锁

  session A启动了事务，占有写锁，还不提交，是导致session B被堵住的原因。可以通过sys.innodb_lock_waits 表查到是谁占着这个写锁。

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

第二类：查询慢

  扫描行数多，所以执行慢
  带lock in share mode的SQL语句，是当前读，因此会直接读到1000001这个结果，所以速度很快；而select * from t where id=1这个语句，是一致性读，因此需要从1000001开始，依次执行undo log，执行了100万次以后，才将1这个结果返回。

小结

  我们在举例加锁读的时候，用的是这个语句，select * from t where id=1 lock in share mode。由于id上有索引，所以可以直接定位到id=1这一行，因此读锁也是只加在了这一行上。
  但如果是下面的SQL语句，

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

  这个语句序列是怎么加锁的呢？加的锁又是什么时候释放呢？