1: 第一类：查询长时间不返回
    show processlist 命令
    a: 等 MDL 锁
    这类问题的处理方式，就是找到谁持有 MDL 写锁，然后把它 kill 掉。
    通过查询 sys.schema_table_lock_waits 这张表，我们就可以直接找出造成阻塞的 process id，把这个连接用 kill 命令断开即可。
    b: 等 flush
    show processlist
    c: 等行锁
    这个问题并不难分析，但问题是怎么查出是谁占着这个写锁。如果你用的是 MySQL 5.7 版本，可以通过 sys.innodb_lock_waits 表查到。

    2: 第二类：查询慢
    a: 看一下慢查询日志。注意，这里为了把所有语句记录到 slow log 里，我在连接后先执行了 set long_query_time=0，将慢查询日志的时间阈值设置为 0。
    b: lock in share mode 的 SQL 语句，是当前读，因此会直接读到 1000001 这个结果，所以速度很快；而 select * from t where id=1 这个语句，是一致性读，因此需要从 1000001 开始，依次执行 undo log，执行了 100 万次以后，才将 1 这个结果返回

    3: 分析语句执行过程: select * from table_a where b=’1234567890abcd’; (b: varchar(10))
    这条 SQL 语句的执行很慢，流程是这样的：

    1. 在传给引擎执行的时候，做了字符截断。因为引擎里面这个行只定义了长度是 10，所以只截了前 10 个字节，就是’1234567890’进去做匹配；
    2. 这样满足条件的数据有 10 万行；
    3. 因为是 select *， 所以要做 10 万次回表；
    4. 但是每次回表以后查出整行，到 server 层一判断，b 的值都不是’1234567890abcd’;
    5. 返回结果是空。