成人国产在线小视频_日韩寡妇人妻调教在线播放_色成人www永久在线观看_2018国产精品久久_亚洲欧美高清在线30p_亚洲少妇综合一区_黄色在线播放国产_亚洲另类技巧小说校园_国产主播xx日韩_a级毛片在线免费

資訊專欄INFORMATION COLUMN

如何不讓一個(gè)慢查詢把服務(wù)器搞冒煙

lscho / 2321人閱讀

摘要：這臺(tái)數(shù)據(jù)庫(kù)的機(jī)器同時(shí)還跑其他業(yè)務(wù)，都是量級(jí)較大的，服務(wù)器負(fù)載本來(lái)就不低，七夕還沒到，就因?yàn)檫@條把服務(wù)器搞的直冒煙，本業(yè)務(wù)慢查詢也拖慢了其他業(yè)務(wù)的執(zhí)行時(shí)間導(dǎo)致連鎖反應(yīng)。

喂？xxx嗎？你們的服務(wù)怎么回事，機(jī)器又掛掉啦~！
?。繏斓魩着_(tái)了？
你們借的40臺(tái)掛了兩臺(tái)啦！
騷等，我看看咋回事！

服務(wù)器又冒煙了~~~原因是這樣的：

前段時(shí)間項(xiàng)目迎來(lái)七夕高峰，有一個(gè)接口的SQL本來(lái)長(zhǎng)這樣：

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的結(jié)果表示并沒有用到有效索引，實(shí)際情況下表里有130w+數(shù)據(jù)的時(shí)候這個(gè)語(yǔ)句跑起來(lái)平均耗時(shí)5s多，這肯定是不能忍受的。

那強(qiáng)制索引怎么樣？試試看：

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，照理說(shuō)在29w里面怎么查都不會(huì)太慢，但是都知道explain里的rows只是個(gè)參考，實(shí)際跑起來(lái)還是花了3s多，也是不能忍受的。

這臺(tái)數(shù)據(jù)庫(kù)的機(jī)器同時(shí)還跑其他業(yè)務(wù)，都是量級(jí)較大的，服務(wù)器負(fù)載本來(lái)就不低，七夕還沒到，就因?yàn)檫@條sql把服務(wù)器搞的直冒煙，本業(yè)務(wù)慢查詢也拖慢了其他業(yè)務(wù)的執(zhí)行時(shí)間導(dǎo)致連鎖反應(yīng)。

之前已經(jīng)對(duì)數(shù)據(jù)的讀取部分加了緩存，但是日志記錄還是顯示某段時(shí)間內(nèi)產(chǎn)生大量的慢查詢請(qǐng)求。開始我們懷疑是緩存失效，但后來(lái)發(fā)現(xiàn)，其實(shí)是高并發(fā)導(dǎo)致在設(shè)置緩存階段，由于sql語(yǔ)句執(zhí)行時(shí)間太長(zhǎng)，導(dǎo)致在這5秒內(nèi)造成大量數(shù)據(jù)庫(kù)慢查詢。

直接說(shuō)解決方案吧：

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

強(qiáng)制使用索引，一定程度上縮短查詢時(shí)間。

寫個(gè)腳本，定時(shí)將查詢結(jié)果保存到memcache里，這個(gè)主要是防止高并發(fā)情況下，等待寫入mc時(shí)造成短時(shí)間大量數(shù)據(jù)庫(kù)訪問。

對(duì)數(shù)據(jù)庫(kù)讀取結(jié)果做緩存。

對(duì)接口結(jié)果做緩存。

做了這5步工作，媽媽再也不用擔(dān)心我的服務(wù)器會(huì)冒煙啦~~

注：后面會(huì)慢慢把其他blog移到這里來(lái)，以后主要在這寫啦。

文章版權(quán)歸作者所有，未經(jīng)允許請(qǐng)勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。

轉(zhuǎn)載請(qǐng)注明本文地址：http://systransis.cn/yun/30394.html

相關(guān)文章

  • 如何不讓一個(gè)慢查詢把服務(wù)器搞冒煙

    摘要：這臺(tái)數(shù)據(jù)庫(kù)的機(jī)器同時(shí)還跑其他業(yè)務(wù)，都是量級(jí)較大的，服務(wù)器負(fù)載本來(lái)就不低，七夕還沒到，就因?yàn)檫@條把服務(wù)器搞的直冒煙，本業(yè)務(wù)慢查詢也拖慢了其他業(yè)務(wù)的執(zhí)行時(shí)間導(dǎo)致連鎖反應(yīng)。 喂？xxx嗎？你們的服務(wù)怎么回事，機(jī)器又掛掉啦~！啊？掛掉幾臺(tái)了？你們借的40臺(tái)掛了兩臺(tái)啦！騷等，我看看咋回事！ 服務(wù)器又冒煙了~~~原因是這樣的： 前段時(shí)間項(xiàng)目迎來(lái)七夕高峰，有一個(gè)接口的SQL本來(lái)長(zhǎng)這樣： mysql>...

    Amio 評(píng)論0 收藏0

  • SegmentFault 技術(shù)周刊 Vol.39 - 什么！服務(wù)器炸了？

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

    1treeS 評(píng)論0 收藏0

  • 留給傳統(tǒng) DBA 的時(shí)間不多了？看餓了么如何構(gòu)建數(shù)據(jù)庫(kù)平臺(tái)自動(dòng)化

    摘要：因?yàn)閭鹘y(tǒng)的數(shù)據(jù)庫(kù)管理方式在當(dāng)前這種架構(gòu)下依靠手工或者借助簡(jiǎn)單的工具是無(wú)法應(yīng)對(duì)多活架構(gòu)大規(guī)模管理帶來(lái)的復(fù)雜性，因此平臺(tái)化顯得非常重。我們?cè)谧龅姆桨笗r(shí)做了充分調(diào)查及論證，最終沒有選擇這種方式。 蔡鵬，2015年加入餓了么，見證了餓了么業(yè)務(wù)&技術(shù)從0到1的發(fā)展過(guò)程，并全程參與了數(shù)據(jù)庫(kù)及DBA團(tuán)隊(duì)高速發(fā)展全過(guò)程。同時(shí)也完成個(gè)人職能的轉(zhuǎn)型-由運(yùn)維DBA到DEV-DBA的轉(zhuǎn)變,也從DB的維穩(wěn)轉(zhuǎn)變到專心為...

    explorer_ddf 評(píng)論0 收藏0

  • 分表后需要注意的二三事

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

    dongxiawu 評(píng)論0 收藏0

發(fā)表評(píng)論

0條評(píng)論

最新活動(dòng)
閱讀需要支付1元查看
<