淺談Mysql高可用，DBA們將如何應(yīng)對(duì)？

shjhcx

一直很喜歡Mysql的路過

stay_sun

回復(fù) 1# cnlnzz01


       1.如果是你，你怎么處理慢查詢引起的問題，并且在以后避免這種情況發(fā)生？
這個(gè)問題要解決的話問題就在研發(fā)的了，最好上sql 審計(jì)的話可以避免問題

     2.除了慢查詢，還有哪些情況會(huì)導(dǎo)致MySQL卡頓，查詢較慢？
         這個(gè)主要有很多主要還是跟調(diào)優(yōu)方面的分類差不多
         硬件征用： 內(nèi)存cpu io  網(wǎng)絡(luò)
         配置方面  內(nèi)存分配不合理  主機(jī)參數(shù)
        sql 設(shè)計(jì)： sql 的鎖 大的sql  搶占資源等
     3.針對(duì)于數(shù)據(jù)庫優(yōu)化，您有哪些比較實(shí)用的建議和想法？
      其實(shí)調(diào)優(yōu)的話還是調(diào)整平衡  看你得消耗了  調(diào)整好 內(nèi)核參數(shù)  配置文件 等
    4.結(jié)合生產(chǎn)環(huán)境，您覺得MySQL，較于PG NOsql DB2 Sybase MongoDB Oracle等數(shù)據(jù)庫來，他的優(yōu)點(diǎn)在哪？在什么情況下你會(huì)使用其它類型的DB
      其實(shí)選擇的話沒有什么最合適的。還是看業(yè)務(wù)吧
      交易系統(tǒng)還是適合oracle
      展示等系統(tǒng) 適合mysql
       redis memcached 做緩存
      mongodb  適合分析
      沒有絕對(duì)的還是看你用什么用的最好把，有時(shí)候用的好的話 還是可以省事好多

    5.如果您是數(shù)據(jù)庫的設(shè)計(jì)者，您會(huì)去怎么設(shè)計(jì)數(shù)據(jù)庫的引擎和結(jié)構(gòu)？
    基本上mysql innodb 存儲(chǔ)引擎為主  表必須主鍵  最好是自增的id 剩下出查詢的索引 就好了

csoho2000

不會(huì)，拿起小板凳圍觀

love100

1. 如果是你，你怎么處理慢查詢引起的問題，并且在以后避免這種情況發(fā)生？
==>對(duì)于這種情況，運(yùn)維是應(yīng)該監(jiān)控，并提前知道的，通過show full processlist;對(duì)于什么用用戶（User）從哪臺(tái)主機(jī)（Host）來在哪個(gè)庫（db）上所執(zhí)行的sql語句運(yùn)行的狀態(tài)（Command），該sql運(yùn)行超過了設(shè)定的時(shí)間（Time）進(jìn)行告警.

2. 除了慢查詢，還有哪些情況會(huì)導(dǎo)致MySQL卡頓，查詢較慢？         
==>禁用DNS反向解析，OS以外的，就用1來監(jiān)控

3. 針對(duì)于數(shù)據(jù)庫優(yōu)化，您有哪些比較實(shí)用的建議和想法？
==>數(shù)據(jù)庫的優(yōu)化，DBA首先要對(duì)業(yè)務(wù)邏輯很熟悉，要在設(shè)計(jì)階段進(jìn)行把控，數(shù)據(jù)類型盡量精準(zhǔn)，盡量避免鎖競(jìng)爭(zhēng)、死鎖（盡可能的避免gap)的情況產(chǎn)生，索引要定期的進(jìn)行檢查，檢查是否合理，是否達(dá)到了最優(yōu).

4. 結(jié)合生產(chǎn)環(huán)境，您覺得 MySQL，較于PG NOsql DB2 Sybase MongoDB Oracle等數(shù)據(jù)庫來，他的優(yōu)點(diǎn)在哪？在什么情況下你會(huì)使用其它類型的DB
  ===》只對(duì)Mysql有研究，其他不太熟悉，目前mysql在我們生產(chǎn)環(huán)境中用于交易系統(tǒng)（外匯、二元期權(quán)、P2P等）此處關(guān)于外匯系統(tǒng)，由于匯率tick數(shù)據(jù)量巨大（接收7家銀行、30個(gè)貨幣對(duì)一周3億條數(shù)據(jù)），后臺(tái)檢索比較麻煩，只能定期進(jìn)行處理，此處感覺不足.
  
5. 如果您是數(shù)據(jù)庫的設(shè)計(jì)者，您會(huì)去怎么設(shè)計(jì)數(shù)據(jù)庫的引擎和結(jié)構(gòu)？
===>我首先會(huì)去花大量的時(shí)間去熟悉業(yè)務(wù)邏輯，然后根據(jù)業(yè)務(wù)需要進(jìn)行設(shè)計(jì)，要讓開發(fā)者完全認(rèn)同你的設(shè)計(jì).

ych20158

這本書其實(shí)還不錯(cuò)，看完就會(huì)覺得不那么高大上，哎，慢慢學(xué)，不要著急啊。

cjfeii

1.如果是你，你怎么處理慢查詢引起的問題，并且在以后避免這種情況發(fā)生？
如果確定是由于慢查詢引起的MySQL數(shù)據(jù)庫性能問題，首先通過“show processlist”以及“slow.log”確定具體哪些慢查詢，確定之后根據(jù)慢查詢不同的情況去優(yōu)化：
    1. 如果是SQL有問題，那么就優(yōu)化SQL；
    2. 優(yōu)化之后的SQL，可以通過添加索引來提升查詢性能，但是，添加索引是一把雙刃劍：會(huì)降低“insert/update”的性能，并且還要占用額外的存儲(chǔ)空間，所以謹(jǐn)慎的對(duì)待添加索引；
    3. 如果添加索引不能很好的提高性能，那么可以根據(jù)數(shù)據(jù)的讀寫特點(diǎn)以及數(shù)據(jù)規(guī)模去選擇合適的存儲(chǔ)引擎，雖然在目前innodb引擎性能很好，支持事務(wù)，用的也很廣泛，但是也不要忽視其他的存儲(chǔ)引擎的優(yōu)勢(shì)，比如TokuDB的高壓縮比以及高insert屬性等；
    4. 如果數(shù)據(jù)規(guī)模超出了單機(jī)MySQL存儲(chǔ)容量范圍，那么就需要擴(kuò)展機(jī)器做集群或者替換MySQL數(shù)據(jù)庫尋求更適合的存儲(chǔ)數(shù)據(jù)庫；

2.除了慢查詢，還有哪些情況會(huì)導(dǎo)致MySQL卡頓，查詢較慢？
引起MySQL卡頓的情況有很多，但是根本原因主要就是CPU以及IO的搶占。比如：
    1. 大規(guī)模的寫會(huì)占用大量的IO資源會(huì)引起MySQL卡頓；
    2. 如果MySQL所在的服務(wù)器上運(yùn)行著其他的應(yīng)用程序，并占用太多的CPU或是IO，那么也會(huì)導(dǎo)致MySQL查詢較慢；
    3. 等等。
生產(chǎn)環(huán)境永遠(yuǎn)是最復(fù)雜的系統(tǒng)，線上MySQL卡頓也會(huì)有多種原因，這就使得掌握查找卡頓原因的方法尤為重要，如：show processlist，top/htop，iostat/iotop，strace等（）。

3.針對(duì)于數(shù)據(jù)庫優(yōu)化，您有哪些比較實(shí)用的建議和想法？
數(shù)據(jù)庫優(yōu)化不是一朝一夕就能做好，在平時(shí)的工作中要一點(diǎn)一滴的來做，不同部門協(xié)同來做：
    1. 數(shù)據(jù)庫設(shè)計(jì)的時(shí)候：合理設(shè)計(jì)表結(jié)構(gòu)以及合理訪問數(shù)據(jù)庫表；
    2. 數(shù)據(jù)庫運(yùn)行過程中，注意性能的監(jiān)控，最直觀的就是：slowlog和show processlist，還需要注意其他指標(biāo)的波動(dòng)（disk, io, net等）；
    3. 優(yōu)化的時(shí)候，要全盤考慮，避免只考慮將來而忘掉過去（程序員會(huì)發(fā)瘋的）；
    4. 等等。

4.結(jié)合生產(chǎn)環(huán)境，您覺得MySQL，較于PG NOsql DB2 Sybase MongoDB Oracle等數(shù)據(jù)庫來，他的優(yōu)點(diǎn)在哪？在什么情況下你會(huì)使用其它類型的DB
相對(duì)于其他關(guān)系型數(shù)據(jù)庫，主要就是：社區(qū)比較活躍，軟件更新快，從業(yè)人員比較多，還有就是免費(fèi)。
和nosql數(shù)據(jù)庫相比，就是：支持事務(wù)，復(fù)雜的sql，穩(wěn)定。
具體選用哪種DB，主要有三個(gè)因素——業(yè)務(wù)數(shù)據(jù)特點(diǎn)、DB的成熟度、團(tuán)隊(duì)的技術(shù)棧。比較主流的SQL+NOSQL就是：MySQL+Redis等。


5.如果您是數(shù)據(jù)庫的設(shè)計(jì)者，您會(huì)去怎么設(shè)計(jì)數(shù)據(jù)庫的引擎和結(jié)構(gòu)？
主要看對(duì)數(shù)據(jù)庫的定位，不同的定位導(dǎo)致不同的底層設(shè)計(jì)（引擎和結(jié)構(gòu)），如果側(cè)重點(diǎn)是事務(wù)型，那么就是MySQL、PG的設(shè)計(jì)等，非事務(wù)的話可以考慮nosql的存儲(chǔ)模式（Log Structured Merge等）。
我說一個(gè)我自己工作中用到的場(chǎng)景：
    有一個(gè)特別大的表，這個(gè)表用于保存終端上傳的數(shù)據(jù)，只增加不修改，并主要承載一些查詢業(yè)務(wù)（主要是范圍查找），目前這張表的存儲(chǔ)引擎是innodb。其實(shí)不管是事務(wù)型的innodb還是非事務(wù)型的MyISAM，底層都是B-樹或是B+樹的存儲(chǔ)結(jié)構(gòu)（其他大部分?jǐn)?shù)據(jù)庫系統(tǒng)也是這樣），都是平衡樹，寫的過程中總會(huì)有blance的時(shí)候，而且會(huì)導(dǎo)致邏輯上相鄰的數(shù)據(jù)在物理上不相鄰，在范圍訪問的過程中會(huì)造成很多的隨機(jī)IO，使得性能有所降低，針對(duì)這樣的情況有沒有更好的存儲(chǔ)方式呢？


拋磚引玉：待后者續(xù)。。。

lsstarboy

遇到慢查詢就想辦法繞過去，特別是那些join了一大堆的sql語句，必須繞過去才行，否則卡住整個(gè)數(shù)據(jù)庫都不是困難的事，雖然原理上來說join效率應(yīng)該不低，但有時(shí)候還真不如把sql拆分，然后再語言（PHP）上來解決。

www_baby

回復(fù) 1# cnlnzz01

之前我用inforbright ，也曾常出現(xiàn)這樣情況，通常是內(nèi)存耗完后發(fā)生。


   

ghostwwl

1. 開慢查詢?nèi)罩?br /> 2. 記得沒錯(cuò)的話 應(yīng)該可以記錄所有沒有使用索引的語句
3. 根據(jù)日志做具體處理
4. innodb 最好每張表 單獨(dú)表空間
5. 看mysql的狀態(tài)值 相關(guān)配置該調(diào)整的調(diào)整


有了一少年宮結(jié)果慢慢處理
如果結(jié)構(gòu)索引沒問題 量大的表 分表才是硬道理

然后 sar ionice iostat 之類 看是否硬件瓶頸