有台服务器，访问量挺大，每天近250w动态pv，数据库查询平均每秒近600次
另一台服务器，跑的程序跟这台一样，不过只有每天约40w动态pv
前段时间连续卡死过几次，当时的状态是
服务器没崩溃，数据库可正常登陆。只是所有的查询都卡在“sending data”状态，长时间无法执行完，这些简单的sql语句，有时候集中在A表上，有时候集中在B表上，同时还有一些卡死在locked状态或update状态
看mysql的说明，sending data状态表示两种情况，一种是mysql已经查询了数据，正在发给客户端；另一种情况是，mysql已经知道某些数据需要去什么地方读取，正在从数据文件中读取
mysql官方说，这不是mysql的bug，但是官方也没说怎么处理......那么，看情况，就应该是配置方面的问题了。
首先从sql优化的角度来查了查，那些卡死的sql语句，都是简单查询，消耗非常低，索引做的非常好，所以觉得应该不是sql语句的问题。而且慢查询日志里也没有出现慢查询。
把表都做了优化，就是optimize table ，过几天发现，还是会出现卡死的情况.....
后来考虑增加并发性能，增加了key_buffer thread_cache 等一系列的内存配置，发现没什么作用。情况依旧
再后来，把query_cache减小到默认值 16M，把一些不怎么变动的数据，做了静态化。惊奇的发现，12天过去了，没再出过问题......
后来想想，修改query_cache可能对这个问题有些帮助，毕竟数据更新比较频繁，query_cache的更新也很频繁。不过看mysql的状态，query_cache的命中率还是相当高的，差不多75％。
觉得问题可能出在程序上，只是没查出来。后来静态化的那些内容，是一些产品的说明文字，一般一个产品的说明也就三五十个汉字。
这里出问题的嫌疑比较大，一个页面有七八个产品，加起来可能三五百个汉字，虽然不多，不过查询很频繁，从这个表上查询的数据量应该是很可观的，mysql会频繁的从这个表拿数据。不过，不过有时候卡死的语句并不是在查询这个表......
手头没有好使的工具，郁闷。反正问题貌似好了，先放下备案吧，等以后水平高些，再来查。
MySQL很容易进程满而死的一个重要原因
建站不容易已经远远超过了我的设想和预期,除了经济上还有技术上的,有些问题不是一般技术人员能解决。不过在这段时间里让我也学会了如何思考问题和解决问题，特别是连续解决了几个问题，可以说真不是开发人员或者别的技术人员能解决的，对此自信心也越来越足了!
谈到这，必须说下我们的源码库www.aspku.net，基本配置，LINUX 9.0系统,JBOSS42 WEB服务，MYSQL，从五一到现在，运行有段时间了，目前的访问量是4000IP左右。
记得以前发生过一个问题也是检查了好久都没解决的，故障一发生CPU就跑到100%左右，系统没响应，MYSQL、JBOSS进程死。当初是通过对一些大数据表建立索引解决的!这次问题现象和这个有点象，死的时候几乎服务没有响应，通过查看后台MYSQL进程，居然已经超过我设置的1000个限制，第1天我把配置改成3000，想想是否跟这个有关，最近的访问量增大了。说实话，我还是不相信并发1000个连接，但事实摆在面前，现在就是1000个进程堵在这!第2天发现3000也不行了，在进程列表中看到基本上很容易就进程满，而且每个进程都在sending data 状态，查找了2天还是无法解决问题，不论是重新配置启动参数还是检查外来攻击都无法解决，按照一些人的说法，把临时缓冲表增大到512M也是没有任何帮助。象这种的每增加个连接都几乎会卡死，而且是sending data 状态!是数据无法发出还是查询不能完成呢?
带着这个问题，跟开发的沟通，是否存在数据死锁或者没有提交的问题，造成的查询锁死!而且有时候是正常，但大部分是不正常的死锁!查了半天，报告说，程序没发现问题，因为根据命令已经能定位到程序的准确代码上了!那么是什么问题呢?
想起以前MS SQLSERVER2000下曾经发生过的数据库损坏的问题，也尝试了修复。根据堵塞命令集中在几个重要的表上，其一是餐馆信息表(4万条记录)，用修复命令都无法修复!发现设置的类型是inoubox ,把类型改成MYISAM 后再修复，修复也没报告什么错误，但重新启动系统后一切问题就解决了! 