今天早上（5月10日）10:52收到短信报警，XXX业务数据库宕机，由于今天一直忙各种问题，所以晚上清闲了才得以排查。我们先看下报警信息，如图：从10:41开始，服务
今天早上（5月10日）10:52收到短信报警，网站空间，XXX业务数据库宕机，由于今天一直忙各种问题，所以晚上清闲了才得以排查。
我们先看下报警信息，如图：
从10:41开始，服务器的SWAP分区报警，之后内存不足报警，再最后内存耗尽被HANG死，导致机器死机。
我分析了慢日志，结果一条统计的SQL语句直接把服务器给搞死了。
这肯定是人为执行的，虚拟主机，从跳板机98.149上登陆SQLYOG上执行的，美国空间，如图：
耗时170秒，而且还是在主库，有业务的机器上运行，导致锁表，其他的进程一直等待，最后越积越多，直接把服务器就给跑崩了。
晚上，我在备库上又执行了一次这条SQL，花费了11分26秒（随着这个表的增大时间还会变慢），……………………
MySQL5.1和MySQL5.5对子查询的性能可谓是相当的差，垃圾中的战斗机，所以必须改用表连接方式进行优化，除非今年刚上市的MySQL5.6，所以这条SQL可以这样优化。
只需要0.01秒就出结果。
所以，我在这里提醒大家一下，凡是这种统计的SQL，而且很复杂的，千万不要在主库上运行，子查询目前的性能还很差。
（注：51CTO新改版后的图片显示很小，如果想看大图，请下载附件里的压缩文件。）
本文出自 “贺春旸的技术专栏” 博客，请务必保留此出处
