mysql 性能容量評估

---

• 分析上線業務場景
• 評估數據庫服務器所需性能指標
• 預估可能成為瓶頸的服務器資源
• 幫助數據庫性能調優

• 磁盤IO性能
• 內存容量
• CPU
• 網絡吞吐量
• 磁盤容量

---

• OLTP/OLAP
• 並發請求
• 讀寫比例
• 數據量
• 冷熱數據比
• 數據分級存儲

• 業務高峰時數據庫的每秒並發訪問量是多少
• 通過應用服務器數量，連接池配置判斷
• 通過產品估算初上線用戶規模和用戶增長速度判斷
• 通過實際業務業務類型判斷
• 並發量相關資源：cpu

• 線上業務select只讀與update/delete/insert寫操作比例
• delete/update通常都是先讀再寫
• insert需要區分數據寫入還是持續insert還是大量導入數據
• 根據業務實際場景分析

• 數據庫服務器存儲設備可擴容能力的上限
• 根據估算的業務量，寫入模式，分析數據增長量
• 預計一個硬件升級周期內數據庫可存放數據的總量，上線時要留好余量
• 數據總量相關資源:磁盤容量

• 熱數據，線上最新一定周期內將被反復訪問的數據
• 冷數據，線上保存着的，最近不會被在線用戶用到的數據
• 估算活躍用戶量，數據增長量等預估熱數據量
• 內存大小盡可足夠存放線上實時熱數據
• 熱數據相關資源：內存

• OLTP/OLAP
• 並發請求
• 讀寫比例
• 數據量
• 冷熱數據比
• 數據分級存儲

---

• 用於存放線上數千萬歌曲信息
• 確定屬於OLTP線上類型數據庫
• 並發請求
• • 50台應用服務器，每台最大連接數100
  • 可能峰值5000qps，並發請求量較大
  • 所以：CPU需求高
• 讀寫比例
• • 訪問模式以用戶列出歌單和播放歌曲時查詢歌曲信息為主，用戶只有只讀查詢
  • 寫數據發生在錄入新歌或修改歌曲信息時后台操作，寫比例小，且為批量導入
  • 讀寫比例：100:1
• 數據總量
• • 估算每首歌信息8K，總計5000萬，總量400G
  • 數據總量增長相對較慢
• 冷熱數據比
• • 5000萬歌曲中大約40%可能被訪問，10%屬於熱點歌曲
  • 熱數據大約<40G
• 數據分級存儲需求
• • 由於沒有用戶產生的數據，歌曲信息無法分級存儲

• 並發請求高-----------------------CPU性能要求高
• 讀占大部分，且熱數據大約40G---內存需求一般>40G
• 數據總量400G--------------------磁盤空間需求一般>400G
• 寫比例較少，且是后台批量--------磁盤IO能力需求一般
• 網絡流量要求：8K*2500（每秒2500首放回給用戶）/1024≈20MB/S，一般

• OLTP/OLAP
• 並發請求
• 讀寫比例
• 數據量
• 冷熱數據比
• 數據分級存儲

• 用於存放理財用戶線上訂單
• 確定屬於OLTP線上類型數據庫
• 業務場景有明顯特征
• • 特定高息產品秒殺銷售時間窗有大量並發訂單寫入
  • 平時只有少量訂單查詢請求，和較低的常規產品購買請求
• 評估應以滿足最關鍵的業務高峰為基准

• 確定屬於OLTP線上類型數據庫
• 並發請求量
• • 秒殺期間持續時間短，但是並發量預估30台應用服務器約2000tps(實際估算，比如限售3億，平均每筆訂單1萬，則會有3萬筆訂單，根據實際情況，3萬筆訂單將在十幾秒賣光，所以，每秒應該有2000筆訂單完成)
  • 所以CPU要求較高
  • 所以網絡要求較高
• 讀寫比例
• • 高峰時寫訂單是主要開銷操作
  • 所以磁盤IO要求很高
• 數據總量
• • 根據業務分析，訂單屬於寫入瞬時量大，總量較小，單筆金額較高
  • 總量預估一年成交百萬單位級別，增長量較穩定
  • 判斷數據存儲需求小於200G
  • 所以磁盤空間需求一般，>200G
• 冷熱數據
• • 峰值寫入為主，內存要求存放熱點期間產生的臟數據即可
  • 總共有3萬筆訂單數據產生，算一算臟數據<10G
• 數據分級存儲需求
• • 用戶訂單業務約定頁面展示最近半年訂單，半年前的需要到歷史查詢頁面專門查詢
  • 因此可以做分級存儲，遷移所有半年前訂單至歷史庫

---

•  硬件性能指標：
• • 磁盤IO性能
  • • 單盤->盤陣
    • SAS-SATA,
    • 機械盤->ssd
  • 內存 較小->較大，
  • cup
  • • 普通->多核，
    • 超線程，
  • 磁盤容量
  • • 單盤->盤陣，
    • 單盤->LVM，
  • 網絡吞吐量
  • • 千兆->萬兆，
    • 單網卡->多路；
•  數據庫業務特點：
• • OLTP/OLAPM,
  • 並發請求------cpu，
  • 讀寫比例
  • • 讀---內存
    • 寫磁盤IO，
  • 數據量--磁盤容量，
  • 冷熱數據比 
  • • 熱數據多--內存，
  • 數據分級存儲--緩解線上磁盤空間壓力
• 性能與成本的平衡

 

 

 

 

 

 

 

正確評估SQL數據庫性能，你必須知道的原理和方法

基本概念

性能問題

什么是性能問題？當系統出現性能問題，那么反過來問為什么說出現了性能問題，或者說到底怎么樣算性能問題呢？

• CPU100%,CPU占有率過高？CPU就算是100%,但是客戶端反饋超快，算不算性能問題呢？
• 剩余內存過低？操作系統剩余內存過低有可能是SQL吃完了，所以不一定。那如何知道SQL使用的內存情況呢？
• 查詢慢？查詢慢，是否就是性能問題？如果一段存儲過程寫了500行，里面關聯幾十個表，有復雜的邏輯運算，執行一次超過3000ms,這是慢還是快呢？所以所謂的查詢慢，也要有評估機制。
• 查詢鏈接超時?查詢超時，鏈接超時就更復雜了，有n多因素影響。
• …………

還有很多情況，客戶都說性能問題。所以到底什么算性能問題呢？我個人認為是：

分為2種情況，第一是新系統運行與經驗系統相差巨大，性能測試和壓力測試不符合預期。第二種是正常運行系統發生與通常情況反映不一致狀態，導致業務運行困難。

通常性能下降是我們說的性能問題，但是：

還有性能突然提升，比如平常打開頁面3秒鍾，突然什么都沒有做變成了0.5秒。算不算性能問題呢？我認為也算性能問題，世界上絕對沒有無緣無故的愛，也沒有無緣無故的恨。所以突然的提升一定隱藏着更為重要的問題！

那么既然有了概念，有哪些關鍵指標來評估數據性能問題呢？有了指標，我們就需要收集指標，所以有昨天的文章。

衡量性能問題的關鍵指標

響應時間（Response Time）

響應時間一般指的是一條SQL 語句執行后得出結果耗費的時間。
而一般用戶使用來說，比如BS結構，響應時間大家一般會認為是訪問頁面到頁面呈現結束，這樣的感官時間。這個時間就需要考慮更多的因素。比如網絡、瀏覽器等等。曾經我碰到的CASE 頁面打開速度超慢，但是數據庫正常，后來分析發現是頁面中潛入的一個很小的GIF影響了。所以要系統來分析。
而執行SQL語句獲得的響應時間是最為純粹的反饋，也是能夠得到准備信息的步驟。
在系統跟蹤的話，可以用SQL profile 來跟蹤響應的內容，分析語句的反饋時間，之后再來詳細講解。

吞吐量（Thougput）

吞吐量是反映系統到底有多繁忙的指標，了解此指標可以更為清晰的知曉系統的使用狀況。
性能監視器中可以用SQL Batch Request/Sec，SQL Transactions /Sec等指標來獲取。

基線 （BaseLine）

BaseLine一直是我強調的指標。
基線是反映系統日常狀況的指標，如果知曉了系統的各種基線值。那么就清楚了底在哪里，天在哪里。這樣才能更容易去判斷和解決問題。 而基線值是靠長期經驗和數據獲取的。

瓶頸（bottleneck）

系統一旦產生了瓶頸，我們就要去判斷瓶頸，而瓶頸一般來說多會有關聯性。比如內存不足可能導致IO過高，IO過高也可能導致CPU等待。
所以准確的知道瓶頸在哪里，這是需要去判斷的。使用性能監視器和分析功能可以快捷的幫助大家分析瓶頸。

調優本質

調優的本質來講，一般的調優都指的是性能出現過高，需要系統穩定的情況。所以本質來講是干以下事情：

降低工作負載

• 減少查詢請求的數量：去除不必要的數據庫訪問
• 降低查詢請求的復雜度：優化查詢邏輯的設計
• 減少查詢請求之間的依賴關系：優化事務的設計和並發性控制

優化系統資源的配置

• 找出系統資源瓶頸，增加相應的資源
• 優化系統資源的分配

性能優化的方法學

如下圖，性能優化涉及的層面有：

• 構架設計
• 查詢優化
• 索引優化
• 並發控制
• 存儲優化
• 服務器優化
  相關優化的成效和收益還要順序，可見下圖：

優化的平衡

• 優化是一個持續的過程，永無止境，解決了當前“最大”的瓶頸后，下一個“最大”的瓶頸又會出現
  要知道何時停止優化
• 優化的內容應該是基於業務需求的優化
• 關注二投資回報率(ROI) ，工程師的時間也是投入，因此要懂得投資回報，需要懂得停止優化！
• 改變選項是最有意義的優化策略，有的優化是業務決定，那么無法改變的時候是否可以改變業務邏輯。
• 實際上，足夠好的性能就足夠了。很多時候足夠即可，而不是去尋找極限！

調優思路

調優思路來說，從理論上，在數據庫構架時候就應該介入。但是通常我們遇到的情況都是半路出來。發生問題才找到DBA。所以遵循的思路可以是如下：

理解瓶頸，知道發生了什么，然后做優化配置，調整執行慢的語句。
然后再反復，反復。

總結

調優是個系統工程，要有敏銳的觸覺，有可能一條參數改變整個系統感受。所以深入理解原理和方法，才能得心應手。 具體的方法，工具等敬請期待新的Blog。

 

 

 

 

 

MySQL准入規范及容量評估

一、數據庫設計

1、表結構設計

 -表中的自增列（auto_increment屬性）推薦使用bigint類型
  -首選使用非空的唯一鍵， 其次選擇自增列或發號器
    不使用更新頻繁的列，盡量不選擇字符串列，不使用UUID MD5 HASH
  -業務中選擇性很少的狀態status、類型type等字段推薦使用tinytint或者smallint類型
  -業務中IP地址字段推薦使用int類型
  -業務活躍的大表中必須有行數據的創建時間字段create_time和最后更新時間字段update_time
  -表中所有字段必須都是NOT NULL屬性，業務可以根據需要定義DEFAULT值
  -用decimal存儲精確浮點數(不要用浮點類型)
  -不推薦使用enum，set，blob，text等類型，對於大表必須將text、blob等類型字段拆分或者獨立建表 

2、索引設計

 -避免冗余索引 ：避免將同一個字段都建立索引，索引的建立需要根據訪問的SQL語句來評估
  -一次查詢，一個表只能用到一個索引，不要對每個查詢條件的字段都單獨建立索引
  -單張表索引數量不超過7，單個索引字段數不超過5  
  -不在null列上加索引
  -不在低基數列上建立索引，例如“性別” 
  -復合索引字段排序，區分度最大的字段放在前面
  -核心SQL優先考慮覆蓋索引
  -對字符串使用前綴索引
  -前綴長度不超過8個字符 ，必須是最左前綴 

3、字符集及校驗集

 -數據庫和表的字符集必須一致，且所有表的字符集必須一致，只能是utf8；數據庫中所有表采用統一的校驗集
  -主、從數據庫的字符集必須一致
  -前端程序字符集或者環境變量中的字符集，與數據庫、表的字符集必須一致 

4、其他要求

 -不推薦使用外鍵，臨時表，視圖，自定義函數，存儲過程以及觸發器
  -SSD硬盤上，單表數據行數不能超過5000萬或者存儲空間不得大於30GB
  -SAS硬盤上，單表數據行數不能超過2000萬或者存儲空間不得大於15GB
  -上線前DBA必須根據1年內的業務訪問量和數據增長量，給出庫、表的擴展方案 

二、SQL編寫

1、select

 -SELECT語句必須指定具體字段名稱，禁止寫成“select *”
  -SELECT語句禁止使用UNION，推薦使用UNION ALL，並且UNION子句個數限制在5個以內 

2、DML

 -INSERT語句必須指定具體的字段名稱，不要寫成INSERT VALUES(……)形式 
  -SQL語句在程序中傳入的參數值類型必須與字段在數據庫中的類型相同 

3、多表聯合查詢

 -多表連接查詢推薦使用別名，且SELECT列表中要用別名引用字段，數據庫.表格式，如“select a.cid  from iknow_qb. tblreply a where …”
  -生產系統中，單個查詢中不推薦將3張表以上（包括3張表）做連接
  -生產系統中，強烈不推薦使用外關聯，包括左外關聯，右外關聯和全外關聯
  -在多表連接的查詢中，驅動表須要選擇結果集較小的表
  -禁止寫成多層子查詢嵌套的SQL語句，推薦改寫成表順序連接的格式
  -盡量不要在INSERT|UPDATE|DELETE|REPLACE語句中進行多表連接操作 

4、事務

 -事務中INSERT|UPDATE|DELETE|REPLACE語句操作的行數控制在2000，以及WHERE子句中IN列表的傳參個數控制在2000
  -批量操作數據時，需要控制事務處理間隔時間，進行必要的sleep，具體值由DBA給出，並且程序必須有中斷處理能力
  -對於有auto_increment屬性字段的表的插入操作，並發需要控制在200/s以內
  -SQL級別/事務級別/主從數據庫中的表存儲引擎類型要一致，存儲引擎混合使用會導致主從數據不一致或主從同步中斷
  -對於同步延遲不敏感的只讀查詢，必須放到從庫上執行；對於同步延遲敏感的只讀查詢，可以放到主庫上執行
  -前端程序中盡量不要使用set語句，包括set names、set sql_mode和set isolation_level等 

5、表掃描方式：

 -SELECT|UPDATE|DELETE|REPLACE要有WHERE子句，且WHERE子句的條件必需使用索引查找
  -生產數據庫中強烈不推薦大表上發生全表掃描，但對於5000行以下的靜態表可以全表掃描
  -業務中大表全表掃描和全表導出（dump）推薦放在備份庫或者線下讀庫中進行
  -WHERE 子句中禁止只使用全模糊的LIKE條件進行查找(如like '%aj%')，必須有其他查詢條件
  -WHERE子句中的索引列或組合索引前導列上不能使用函數 

6、排序和分組

 -有distinct、order by和group by子句的查詢，中間結果集限制10000行以內
  -對於大結果集（中間結果集超過10000行）的排序、分組放到程序端實現 

7、其他要求

 -單個SQL語句的大小限制在5MB以內
  -生產數據庫中SQL語句的中間結果集和最終結果集必須限制在5MB以內
  -生產數據庫中SQL語句禁止使用提示，如force index，ignore index，straight_join，sql_no_cache等
  -禁止使用全文檢索功能
  -禁止使用事件（EVENT）功能
  -程序中不要使用或操作mysql庫和test庫，禁止創建test或以test開頭的庫
  -禁止在mysql中使用用戶自定義變量
  -線上數據庫中不要進行業務的實時統計或者匯總等計算操作，可導出后利用其它工具或者在線下備份庫中完成
  -減少與數據庫的交互次數 
        INSERT ... ON DUPLICATE KEY UPDATE 
        REPLACE  INTO、INSERT IGNORE 、INSERT INTO VALUES(),(),()
        UPDATE … WHERE ID IN(A,B,C,…)
  -不使用負向查詢，例如 not in，!= ，not like
  -不在索引列進行數學運算和函數運算 
  -不使用%前導的查詢，例如like “%abc”
  -避免大表數據類型間的隱式轉換(這個經常出性能問題)會導致索引失效，例如數字轉字符串 

三、MySQL相關特點介紹

1、MySQL對SQL的處理特點

 -SQL請求處理只能使用一個核
  -沒有SQL編譯緩存,SQL存儲過程都是硬解析
  -索引上不支持運算對比
  -大多情況下一個Query只能使用一個索引
  -不支持Hash jion(MariaDB目前支持)
  -基於線程的對外服務模型(連接數太高,性能下降嚴重)
  -子查詢支持較差，外層查詢一般走不了索引 

2、MySQL支持的存儲大小

 -單個表空間64T, 每個表只有一個表空間,也就是每個單表最大64T
  -Innodb Logfile 加起來不能超過512G
  -每行大小限制65535 byte 
  -每個表最多1027個字段
  -每個表最多64個普通索引 

3、MySQL生產參考指標

 -單實例最好不要超過1T, 周邊LOG除外,最大不建議超過5T
  -一般的OLTP單表建議最大不要超過10G 
  -通常在有buffer命中的情況下:
        Select 可以達到3-6W/S
        Insert 在聚集索引連續的情況可以到2w-3W/S
        在聚集索引不連續的情況下有可能也就是200-300/S
        UPDATE數據在內存的情況下可以達到3K/S
        DELETE數據在內存的情況下可以達到1k/s,有可能更少
  -數據庫的瓶頸： IO能力 ,想辦法用順序IO,減少隨機IO 

四、建表審核

五、容量評估

1、容量評估概述
        所有的數據庫上線：新建集群、新建數據庫、新建表，都需要提前進行容量評估，防止后續因容量問題而又對已上線的業務進行調整、擴容、遷移等操作，從而對線上業務造成影響。容量包括：訪問量(讀寫)、數據及增長量、磁盤空間容量. 

2、表容量
        表容量主要從表的記錄數、平均長度、增長量、讀寫量、總大小量進行評估。一般對於OLTP的表，建議單表不要超過2000W行數據量，總大小15G以內。訪問量：單表讀寫量在1600/s以內。
        對於單表數據量上百萬的表，每行記錄長度不要過長，不要和text、blob等字段類型放在同一個表中。(MySQL數據頁大小為16K，每行記錄越長，每個數據頁存儲的記錄數就越少，因此在對數據進行檢索時，會產生更多的IO) 

3、實例容量
        MySQL是基於線程的服務模型，因此在一些並發較高的場景下，單實例並不能充分利用服務器的CPU資源，吞吐量反而會卡在mysql層，特別是對於mysql5.5版本。在mysql 5.6版本中 做了很大優化，而且percona 版本有thread pool ，可以充分應對高並發場景下CPU上下文切換消耗過高的問題。
        單實例QPS吞吐量一般控制在20000/s以內，寫入量還需考慮從庫延遲問題，對於mysql5.6版本可以考慮進行分庫后再分表，充分利用5.6版本基於庫級別的多線程復制，從而提高寫入的吞吐量。 

4、磁盤空間
        服務器一般會承載多個數據庫實例，因此在各個實例上線前，需要對各個實例進行 數據量的評估，以及1-2年內 主要的幾個大表的增長量情況，對數據量的評估，盡量精確到每個字段。對於增長量不是特別快的業務(半年就翻倍的情況)，建議1-2年的數據量，最終占磁盤使用率的70%以內。同時，對於一些數據增長較快，可以考慮使用大的慢盤進行數據歸檔。