Mysql sending data 问题

最近公司服务器上总是出现Mysql卡死的问题， 用 show processlist 命令打印出很多进程卡死在sending data 状态。一开始为了快速的回复正常状态， 我尝试使用了如下的命令：

SELECT GROUP_CONCAT(CONCAT('KILL',id,';') SEPARATOR ' ')  from information_schema.processlist WHERE command NOT in ('Sleep'， ‘Binlog dump’) And Time > 'TIME_LIMIT_HERE'

最先的时候使用了Kill Query, 发现根本无效，随后改为 Kill 才可以真正的抹掉进程. Mysql 官方说Kill query 会终结正在当前连接的操作（statement ) 但是保持连接的完整性， 而Kill 就是终止连接。 难道在sending data 状态的Executing 已经不属于操作（statement ) 的范畴了吗， 这个还有待考证。

Mysql 在短暂的回复后马上又有大量的操作停留在sending data的状态在，看来这个治标不治本的方法行不通，没办法由于合同的Availability的问题没有太多时间分析，只能重启Mysql和 JBOSS了。

随后Google了一下，发现网上有很多人遇到了类似的问题， 而大多数问题的焦点在Query cache上。 过大的 Query cache 会引起资源的互斥，因为Mysql在query cache 上只有一个全局锁， 搜寻query cache的键匹配， 把select的结果写入cache, 各种更新操作对cache失效化都会尝试得到这个全局锁。 Mysql 论坛上有人说这个query cache 的值不能超过100M， 甚至100M都过大了。 Mysql 自带的最大的配置query cache size
也只是设到了32M，我们的设置尽然设到了186M，明显过大了。网络上各路外国友人都说对于大并发的应用，更新操作比较平凡的状况下我们应该把query cache 设为完全禁止。  关于禁止query cache 的配置：

query_cache_type

 这个可以被设置为 (只能是数字)

选项	含义
0	(OFF, 不缓存或重新得到结果)
1	(ON, 缓存所有的结果，除了  SELECT SQL_NO_CACHE ...  查询)
2	(DEMAND, 仅缓存  SELECT SQL_CACHE ...  查询)