首先说明一下，这是个无头的案子，虽然问题貌似解决了，不过到现在我也没有答案，只是把这个问题拿出来晾晾 有台服务器，访问量挺大，每天近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会频繁的从这个表拿数据。不过，不过有时候卡死的语句并不是在查询这个表......
手头没有好使的工具，郁闷。反正问题貌似好了，先放下备案吧，等以后水平高些，再来查。

评论 (0) All

登陆 还没注册？