記錄一次子查詢引起的宕機

今天早上5月10日）10:52收到簡訊警示，XXX業務資料庫宕機，由於今天一直忙各種問題，所以晚上清閑了才得以排查。

我們先看下警示資訊，

650) this.width=650;" src="http://www.bkjia.com/uploads/allimg/131228/224P5CP-0.jpg" title="1.jpg" />

從10:41開始，伺服器的SWAP分區警示，之後記憶體不足警示，再最後記憶體耗盡被HANG死，導致機器死機。

我分析了慢日誌，結果一條統計的SQL語句直接把伺服器給搞死了。

這肯定是人為執行的，從跳板機98.149上登陸SQLYOG上執行的，

650) this.width=650;" src="http://www.bkjia.com/uploads/allimg/131228/224P5O45-1.jpg" title="2.jpg" />

耗時170秒，而且還是在主庫，有業務的機器上運行，導致鎖表，其他的進程一直等待，最後越積越多，直接把伺服器就給跑崩了。

晚上，我在備庫上又執行了一次這條SQL，花費了11分26秒隨著這個表的增大時間還會變慢），……………………

650) this.width=650;" src="http://www.bkjia.com/uploads/allimg/131228/224P5K43-2.jpg" title="3.jpg" />

MySQL5.1和MySQL5.5對子查詢的效能可謂是相當的差，垃圾中的戰鬥機，所以必須改用表串連方式進行最佳化，除非今年剛上市的MySQL5.6，所以這條SQL可以這樣最佳化。

650) this.width=650;" src="http://www.bkjia.com/uploads/allimg/131228/224P5N00-3.jpg" title="子查詢.jpg" />

650) this.width=650;" src="http://www.bkjia.com/uploads/allimg/131228/224P5G21-4.jpg" title="4.jpg" />

只需要0.01秒就出結果。

所以，我在這裡提醒大家一下，凡是這種統計的SQL，而且很複雜的，千萬不要在主庫上運行，子查詢目前的效能還很差。

註：BKJIA新改版後的圖片顯示很小，如果想看大圖，請下載附件裡的壓縮檔。）

本文出自 “賀春暘的技術專欄” 部落格，請務必保留此出處http://hcymysql.blog.51cto.com/5223301/1197663