如何不讓一個慢查詢把服務器搞冒煙

lscho 發布于2019-07-01 12:17 / 2320人閱讀

摘要：這臺數據庫的機器同時還跑其他業務，都是量級較大的，服務器負載本來就不低，七夕還沒到，就因為這條把服務器搞的直冒煙，本業務慢查詢也拖慢了其他業務的執行時間導致連鎖反應。

喂？xxx嗎？你們的服務怎么回事，機器又掛掉啦~！
啊？掛掉幾臺了？
你們借的40臺掛了兩臺啦！
騷等，我看看咋回事！

服務器又冒煙了~~~原因是這樣的：

前段時間項目迎來七夕高峰，有一個接口的SQL本來長這樣：

mysql> explain SELECT *,sum(num) AS sum FROM search WHERE search_time >= "2016-08-30" AND type = 0 AND state = 1 GROUP BY keyword ORDER BY sum DESC LIMIT 50;
+----+-------------+-----------+------+--------------------------+------+---------+-------+--------+----------------------------------------------+
| id | select_type | table     | type | possible_keys            | key  | key_len | ref   | rows   | Extra                                        |
+----+-------------+-----------+------+--------------------------+------+---------+-------+--------+----------------------------------------------+
|  1 | SIMPLE      | search | ref  | type,search_time,keyword | type | 2       | const | 651114 | Using where; Using temporary; Using filesort |
+----+-------------+-----------+------+--------------------------+------+---------+-------+--------+----------------------------------------------+

search_time,type,state都建了索引，type和state取值范圍有限，所以基本沒啥用，主要是靠search_time，但是explain的結果表示并沒有用到有效索引，實際情況下表里有130w+數據的時候這個語句跑起來平均耗時5s多，這肯定是不能忍受的。

那強制索引怎么樣？試試看：

mysql> explain SELECT *,sum(num) AS sum FROM search FORCE INDEX (search_time) WHERE search_time >= "2016-08-30" AND type = 0 AND state = 1 GROUP BY keyword ORDER BY sum DESC LIMIT 50;
+----+-------------+-----------+-------+---------------------+-------------+---------+------+--------+---------------------------------------------------------------------+
| id | select_type | table     | type  | possible_keys       | key         | key_len | ref  | rows   | Extra                                                               |
+----+-------------+-----------+-------+---------------------+-------------+---------+------+--------+---------------------------------------------------------------------+
|  1 | SIMPLE      | search | range | search_time,keyword | search_time | 4       | NULL | 290616 | Using index condition; Using where; Using temporary; Using filesort |
+----+-------------+-----------+-------+---------------------+-------------+---------+------+--------+---------------------------------------------------------------------+

有效果，rows降到29w，照理說在29w里面怎么查都不會太慢，但是都知道explain里的rows只是個參考，實際跑起來還是花了3s多，也是不能忍受的。

這臺數據庫的機器同時還跑其他業務，都是量級較大的，服務器負載本來就不低，七夕還沒到，就因為這條sql把服務器搞的直冒煙，本業務慢查詢也拖慢了其他業務的執行時間導致連鎖反應。

之前已經對數據的讀取部分加了緩存，但是日志記錄還是顯示某段時間內產生大量的慢查詢請求。開始我們懷疑是緩存失效，但后來發現，其實是高并發導致在設置緩存階段，由于sql語句執行時間太長，導致在這5秒內造成大量數據庫慢查詢。

直接說解決方案吧：

縮小查詢范圍，由之前的查詢3天改為查詢1天，量級降到130w+數據。

強制使用索引，一定程度上縮短查詢時間。

寫個腳本，定時將查詢結果保存到memcache里，這個主要是防止高并發情況下，等待寫入mc時造成短時間大量數據庫訪問。

對數據庫讀取結果做緩存。

對接口結果做緩存。

做了這5步工作，媽媽再也不用擔心我的服務器會冒煙啦~~

注：后面會慢慢把其他blog移到這里來，以后主要在這寫啦。

云服務器 GPU云服務器如何搞一個自己的hyp加速專線如何把手機變成一個云服務器想搞一個云服務器編程用c語言搞一個心形

文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。

轉載請注明本文地址：http://m.specialneedsforspecialkids.com/yun/30394.html

如何不讓一個慢查詢把服務器搞冒煙

摘要：這臺數據庫的機器同時還跑其他業務，都是量級較大的，服務器負載本來就不低，七夕還沒到，就因為這條把服務器搞的直冒煙，本業務慢查詢也拖慢了其他業務的執行時間導致連鎖反應。喂？xxx嗎？你們的服務怎么回事，機器又掛掉啦~！啊？掛掉幾臺了？你們借的40臺掛了兩臺啦！騷等，我看看咋回事！服務器又冒煙了~~~原因是這樣的：前段時間項目迎來七夕高峰，有一個接口的SQL本來長這樣： mysql>...

Amio 2019-08-06 12:25 評論0 收藏0
SegmentFault 技術周刊 Vol.39 - 什么！服務器炸了？

摘要：有一次別人的云服務器被攻擊，提供商竟然重啟了物理機然后又諸多悲劇出現。造成微博服務短暫不可用。通過建立工具來診斷問題，并創建一種復盤事故的文化來推動并作出改進，防止未來發生故障。 showImg(https://segmentfault.com/img/bV0jif?w=900&h=385); 相信小伙伴們在上網或者玩游戲的時候一定都遇到過無法訪問的情況。服務器炸了的原因有各種各樣，下...

1treeS 2019-05-28 17:03 評論0 收藏0
留給傳統 DBA 的時間不多了？看餓了么如何構建數據庫平臺自動化

摘要：因為傳統的數據庫管理方式在當前這種架構下依靠手工或者借助簡單的工具是無法應對多活架構大規模管理帶來的復雜性，因此平臺化顯得非常重。我們在做的方案時做了充分調查及論證，最終沒有選擇這種方式。蔡鵬，2015年加入餓了么，見證了餓了么業務&技術從0到1的發展過程，并全程參與了數據庫及DBA團隊高速發展全過程。同時也完成個人職能的轉型-由運維DBA到DEV-DBA的轉變,也從DB的維穩轉變到專心為...

explorer_ddf 2019-04-25 17:21 評論0 收藏0
分表后需要注意的二三事

摘要：分表字段的選擇。問題產生之前提到在分表應用上線前我們需要將原有表的數據遷移到新表中，這樣才能保證業務不受影響。雖說凌晨的業務量下降，但依然有少部分的請求過來，也會出現各種數據庫異常。 showImg(https://segmentfault.com/img/remote/1460000019462791?w=496&h=285); 前言本篇是上一篇《一次分表踩坑實踐的探討》，所以還沒...

dongxiawu 2019-08-19 11:43 評論0 收藏0