MYSQL性能管理及架構設計-1

用心分享每一篇乾貨
一
是什麼決定了電商雙11大促的成敗？！

就按照市面上的上線電商平臺而言，一個交互性優越的前端架構，一個或多個web服務器（可橫向擴展）及數據庫服務器。

那麼問題來了，數據庫服務器並不能和web服務器同樣進行橫向擴展，畢竟不是代碼，不能隨意的粘貼複製，那麼咱們就來聊聊雙11中的大促中電商們的數據庫架構。

通常均爲一個主服務器、多個從服務器

Master——Slave×N

期間沒有主從複用組件，一旦主服務器出現故障、不能立馬切換

那麼大促中什麼影響了數據庫性能呢？

sql查詢速度、服務器硬件、網卡流量、磁盤IO

超高的QPS和TPS

風險：效率底下的SQL（mysql並不支持多cpu併發查詢）

QPS：每秒鐘處理的查詢量

大量的併發和超高的CPU使用率

風險：大量的併發——數據庫鏈接數被佔滿（max_connections默認100）

超高的CPU使用率——因CPU資源耗盡而出現宕機

磁盤IO

風險：磁盤IO性能忽然降低（使用更快的磁盤設備）

其餘大量消耗磁盤性能的計劃任務（調整計劃任務，作好磁盤維護）

網卡流量

風險：網卡IO被佔滿（1000Mb）

旅行 心率圖分割線
如何避免沒法鏈接數據庫的狀況：

一、減小從服務器的數量

二、進行分級緩存

三、避免使用「 SELECT * 」進行查詢

四、分離業務網絡和服務器網絡

固然對於大型電商而言，還有大表給他們帶來的各類問題

什麼樣的表能夠稱之爲大表？這只是相對而言

·記錄行數巨大，單表超過千萬行

·表數據文件巨大，表數據文件超過10G

大表對查詢的影響：

慢查詢：很難再必定的時間內過濾出所須要的數據

顯示訂單——來源少——區分度低——大量磁盤IO——下降磁盤效率——大量慢查詢

大表對DDL操做的影響：

創建索引須要很長時間

風險：MYSQL版本<5.5 創建索引會鎖表

MYSQL版本>=5.5 雖然不會鎖表但會引發主從延遲

修改表結構須要長時間鎖表

風險：會形成長時間的主從延遲（主從複製爲單線程）

影響正常的數據操做

如何處理數據庫中的大表

一、分庫分表把一張大表分紅多個小表

難點：分表主鍵的選擇、分表後跨分區數據的查詢和統計

二、大表的歷史數據歸檔

減小對先後端業務的影響

難點：歸檔時間點的選擇、如何進行歸檔操做

除了大表 必定就還有大事務啦！

一、事務是數據庫系統區別於其餘一切文件系統的重要特性之一

二、事務是一組具備原子性的SQL語句，或是一個獨立的工做單元

事務———原子性、一致性、隔離性、持久性

事務的原子性（ATOMICITY）

定義：一個事務必須被視爲一個不可分割的最小工做單元，整個事務中的全部操做要麼所有提交成功，要麼所有失敗，對於一個事務來講，不可能只執行其中的一部分操做

（整個事務中的全部操做要麼所有提交成功，要麼所有失敗回滾）

事務的一致性（CONSISTENCY）

定義：一致性是指事務將數據庫從一種一致性狀態轉換到另外一種一致性狀態，在事務開始以前和事務結束後數據庫中數據的完整性沒有被破壞

事務的隔離性（ISOLATION）

定義：隔離性要求一個事務對數據庫中數據的修改，在未提交完成以前對於其餘事務是不可見的

SQL標準中定義的四種隔離級別

·未提交讀（READ UNCOMMITED）

·已提交讀（READ COMMITED）

·可重複讀（REPEATABLE READ）

·可串行化（SERIALIZABLE）

（隔離性由低到高、併發性由高到低）

事務的持久性（DURABILITY）

定義：一旦事務提交，則其所作的修改就會永久保存到數據庫中。此時即便西永崩潰，已經提交的修改數據也不會丟失

什麼是大事務

定義：運行時間比較長，操做的數據比較多的事務

風險：鎖定太多的數據，形成大量的阻塞和鎖超時、回滾時所需時間比較長、執行時間長，容易形成主從延遲

如何處理大事務

一、避免一次處理太多的數據

二、移除沒必要要在事務中的SELECT操做