MySQL單機load過高問題討論
有一個朋友問我: "hi,我想問下你們遇到單機load過高的情況 采取什麼緊急措施啊?"
我問他是不是mysql db server？
他說是。
我給他如下建議：
1 先看下是不是mysqld進程造成的load高？
2 如果是的話，去看下當前線程有沒有比較慢的sql
朋友再問： 嗯 都沒有呢，這個如果由於業務的原因導致load高呢
我給出自己的建議：
1 並發量過高
2 業務原因，是crontab 任務，可以停止就停止掉
朋友再問：不是 sql的原因啊 db機器一般出現load高都是因為io，cpu這些導致的 這些很大部分都是由於業務繁忙處理不過來吧
我回復 ：
1 嗯，不是慢sql導致io cpu爆增的，我還沒碰到過,可能是我們這邊單機性能太好瞭, [做人要坦誠特別是技術討論]
2 如果是io，cpu，那也是有事務操作吧
3 看看db參數設置是否合理,如果參數合理的話，估計就是到瞭單機性能的瓶頸瞭
朋友問：額 沒有遇到過 …. 這，那沒有遇到過db機器load高需要處理的啊？
我回復：
遇到很多，大部分都是慢sql造成的
朋友再問：嗯 一般不急？
我回復：
1 嗯，不會啊，我們事先上應用之前都會做壓力測試，峰值測試
2 業務量不會超過預計的峰值
3 你們單臺load過高，現在mysql不都是多臺嗎？分佈式，讀寫負載均衡，一臺load過高，那另外幾臺呢？
朋友再問： 我假設某個業務 突然一天訪問量很高（超過之前預估），這個時候又隻訪問一個主，而業務肯定不能停的，機器明顯感覺處理不過來，load急速上升，有什麼辦法處理嗎？我們的不是不是分佈式的，現在的分佈式都有負載均衡，對這樣的情況太好處理瞭。
我回復：
1 這個時候業務不能停，單機硬件升級更不是可行方案。
2 在發現cpu過高瞭，就馬上去準備加新的db機器，如果新的db機器在單臺db爆掉之前準備好的話，直接添加上去，分擔app訪問壓力。
3 這個操作不會對業務產生影響，我們一般用的都是vip吧，在vip下再加一臺db，應該是很方便的。
朋友再問： 我在想這樣的問題還真是有點難處理啊？
我表示疑惑：為什麼，你們不是用vip訪問db？
朋友說：不是，都是直接寫真實ip上去連接應用的。
說道這裡，如果沒有vip，而且是單臺db，到時候瞬間爆掉瞭，我隻能表示我水平有限暫時也沒有別的好招瞭，隻有暫停業務並且重新架構db瞭。
不過我還是給他一些自己的建議，希望能帶給他一些幫組：
1 上新的app之前，做好db的壓力測試和峰值測試。
2 要做db的ha方案，並且測試通過。
3 db的ip已經app的ip已經要用類似vip的處理方式，以便方便擴展。
4 db要做好備份機制，並隨時抽查備份的有效性。