问题：
我执行了一个sql，五六分钟没有执行成功，然后我就ctrl +c，没成功，然后我就kill，之后显示成功，但是处于killed状态，事务还在。这是一个从库，那之后从库应用的sql，也就是一个很简单的插入sql，跟我执行的sql没有任何关联关系，也执行不了了，主从也就发生阻塞了。我查看了系统io，cpu，都没有什么问题。现在，我想use information_schema都不行了。这是为什么，是什么原因一个SQL会导致mysql卡的不行，其他都执行不了。
排错过程：
执行的sql：
SELECTorderId,serviceSubItemId,itemCount,isApproval,priceType,serviceType,materialsId,0price,1 isChoice FROM
(SELECT orderId,COUNT(serviceSubItemId) size,serviceSubItemId,itemCount,isApproval,
CASE WHEN priceType = '1' THEN '2' ELSE '1' END ASpriceType,serviceType,materialsId FROM `carrepairitem`
WHERE LENGTH(orderId) <10 AND isChoice = 1 GROUP BYorderId,serviceSubItemId)a WHERE a.size = 1
查看数据库状态：
Show processlist；
之后不出结果卡那不动
然后我Ctrl + C，不成功，还是卡在那
我就新开了个窗口，将其kill掉，执行完成，显示成功。
再次查看一下数据库状态：
发现command显示killed，当时也没有多想，之后发现主从同步的sql被阻塞了，但是这两个表没有任何的关联关系，而且这条应用的sql只是一条简单地insert语句，自己的sql怎么会阻塞呢。
查了一下processlist里面的killed：
Killed：有人发送一个KILL线程的语句,它应该中止在下一次检查杀死标志
感觉没什么问题，就算是在回滚数据，也不会影响其他表吧。
查看锁及锁等待
然后通过select * from information_schema.innodb_locks以及
select * from information_schema.innodb_lock_waits发现没有行锁及锁等待。
然后show processlist以及show engine innodb status \G查看状态
也没有发现表锁以及死锁。
之后想会不会是触发器之类的。
然后查看了一下触发器信息
Show triggers from koala;
结果也卡那不动了，而且Ctrl + C也关闭不了。
这时查看数据库状态
Show processlist；
然后将其kill掉，在查看状态
发现又是killed
查看服务器io，cpu，磁盘，内存状态，也没有什么异常
Iotop
perf top -p `pidof mysqld`
最后实在没办法，查了一下processlist里面状态
Creating sort index：线程正在处理一个SELECT，使用内部临时表解决
于是想是不是数据库内存大小的问题
比如innodb_buffer_pool_size，table cache等
然后查看了一下buffer_pool状态
Show variables like ‘%buffer_pool%’
发现innodb_buffer_pool_size只有5M，感觉原因就是因为buffer pool过小，
增加buffer_pool的大小到20G
mysql> select 20*1024*1024*1024;
+-------------------+
| 20*1024*1024*1024 |
+-------------------+
| 21474836480 |
+-------------------+
1 row in set (0.00 sec)
mysql> set global innodb_buffer_pool_size=21474836480;
再查看一下buffer pool的大小
最后查看数据库状态，发现已经正常了。
总结：
平时除了查看mysql基本的状态，还要对内存等进行合理的分配，防止过小而出现问题。
随着数据量的不断增加，也需要对一些参数进行优化。