MYSQL數(shù)據(jù)庫學(xué)習(xí)系列四

                  MySQL數(shù)據(jù)庫學(xué)習(xí)系列四

四．MYSQL的應(yīng)用優(yōu)化
4.1-MySQL索引優(yōu)化與設(shè)計
什么是索引
?索引的意義 —— 快速定位要查找的數(shù)據(jù)
數(shù)據(jù)庫索引查找
?全表掃描 VS 索引查找
如何根據(jù)首字母找到所在行
?二分查找
?B+tree
InnoDB表聚簇索引
索引中只放著排序字段和ID
創(chuàng)建索引
?單列索引
create index idx_test1 on tb_student (name);
?聯(lián)合索引
create index idx_test2 on tb_student (name, age);
?索引中先根據(jù)name排序，name相同的情況下，根據(jù)age排序
索引維護(hù)
?索引維護(hù)由數(shù)據(jù)庫自動完成
?插入/修改/刪除每一個索引行都會變成一個內(nèi)部封裝的事務(wù)
?索引越多，事務(wù)越長，代價越高
?索引越多對表的插入和索引字段修改就越慢
?控制表上索引的數(shù)量，切忌胡亂添加無用索引
如何使用索引
?依據(jù)WHERE查詢條件建立索引
select a, b from tab_a where c=? ;
idx_c (c)select a, b from tab_a where c=? and d=?;
idx_cd (c, d)
?排序order by, group by, distinct字段添加索引
select from tb_a order by a;select a, count() from tb_a group by a;
idx_a (a)
select from tb_a order by a, b;
idx_a_b (a, b)
select from tb_a order where c=? by a;
idx_c_a (c, a)
索引與字段選擇性
?
某個字段其值的重復(fù)程度
?
?
選擇性很差的字段通常不適合創(chuàng)建單列索引
?
o男女比例相仿的列表中性別不適合創(chuàng)建單列索引
o如果男女比例極不平衡，要查詢的又是少數(shù)方(理工院校查女生)可以考慮使用索引
?
聯(lián)合索引中選擇性好的字段應(yīng)該排在前面
?
select from tab_a where gender=? and name=?;
idx_a1 (name, gender)
聯(lián)合索引與前綴查詢
?聯(lián)合索引能為前綴單列，復(fù)列查詢提供幫助
idx_smp (a, b, c)where a=? ;where a=? and b=? ;where a=? and c=? ;(部分ok)
?合理創(chuàng)建聯(lián)合索引，避免冗余 (a) , (a, b) , (a, b, c) X (a, b, c) ok
長字段上的索引
?在非常長的字段上建立索引影響性能
?InnoDB索引單字段(utf8)只能取前767 bytes
?對長字段處理的方法
oEmail類，建立前綴索引
Mail_addr varchar(2048)
idx_mailadd (Mail_addr(30)) ok
o住址類，拆分字段
Home_address varchar(2048)
idx_mailadd (Mail_addr(30)) ? -- 很可能前半段都是相同的省市區(qū)街道名稱
Province varchar(1024), City varchar(1024), District varchar(1024), Local_address varchar(1024) ... -- 建立聯(lián)合索引或單列索引
索引覆蓋掃
?最核心SQL考慮索引覆蓋
select Name from tb_user where UserID=?
Key idx_uid_name(UserID, Name)
?
?不需要回表獲取name字段，IO最小，效率最高
無法使用索引的情況
?索引列進(jìn)行數(shù)學(xué)運(yùn)算或函數(shù)運(yùn)算
where id+1=10; Xwhere id = (10-1); ok
year(col) < 2007; X
col < '2007-01-01'; ok
?
?未含符合索引的前綴字段
Idxabc (a, b, c):where b=? and c=?; X
(b, c) ok
?
?前綴通配,''和'%'通配符
Like '%xxx%'; XLike 'xxx%'; ok
?
?where 條件使用NOT, <>, !=
?字段類型匹配
o并不絕對，但是無法預(yù)測地會造成問題，不要使用
a int(11), idx_a (a)where a = '123'; Xwhere a = 123 ; ok
利用索引排序
idx_a_b (a, b)
?能夠使用索引幫助排序的查詢：
order by a
a = 3 order by border by a, border by a desc, b desc
a > 5 order by a
?不能使用索引幫助排序的查詢：
order by b
a > 5 order by b
a in (1, 3) order by border by a asc, b desc
如何確定一個查詢走沒走索引，走了哪個索引
?explain是確定一個查詢?nèi)绾巫咚饕詈啽阌行У姆椒?explain select from tb_test ;
?關(guān)注的項目
otype:查詢access的方式
okey:本次查詢最終選擇使用哪個索引，NULL為未使用索引
okey_len:選擇的索引使用的前綴長度或者整個長度
orows:可以理解為查詢邏輯讀，需要掃描過的記錄行數(shù)
oextra:額外信息，主要指的fetch data的具體方式
4.2-MySQL數(shù)據(jù)庫設(shè)計
什么是Schema設(shè)計
?設(shè)計數(shù)據(jù)庫的表，索引，以及表和表的關(guān)系
o在數(shù)據(jù)模型的基礎(chǔ)上將關(guān)系模型轉(zhuǎn)化為數(shù)據(jù)庫表
o滿足業(yè)務(wù)模型需要基礎(chǔ)上根據(jù)數(shù)據(jù)庫和應(yīng)用特點(diǎn)優(yōu)化表結(jié)構(gòu)
為什么Schema需要設(shè)計
?Schema關(guān)系到應(yīng)用程序功能與性能
o滿足業(yè)務(wù)功能需要
o同性能密切相關(guān)
o數(shù)據(jù)庫擴(kuò)展性
o滿足周邊需求(統(tǒng)計，遷移等)
?關(guān)系型數(shù)據(jù)庫修改Schema經(jīng)常是高危操作
oSchema設(shè)計要體現(xiàn)一定的前瞻性
完全由開發(fā)者主導(dǎo)的Schema設(shè)計
?著眼于實現(xiàn)當(dāng)前功能
?完全基于功能的設(shè)計可能存在一些隱患
o不合理的表結(jié)構(gòu)或索引設(shè)計造成性能問題
o沒有合理評估到數(shù)據(jù)量的增長造成空間緊張而且難以維護(hù)
o需求頻繁修改造成表結(jié)構(gòu)經(jīng)常變更
o業(yè)務(wù)重大調(diào)整導(dǎo)致數(shù)據(jù)經(jīng)常需要重構(gòu)訂正
基于性能的表設(shè)計
?根據(jù)查詢需要設(shè)計好索引
?根據(jù)核心查詢需求，適當(dāng)調(diào)整表結(jié)構(gòu)
?基于一些特殊業(yè)務(wù)需求，調(diào)整實現(xiàn)方式
索引
?正確使用索引
?更新盡可能使用主鍵或唯一索引
?主鍵盡可能使用自增ID字段
?核心查詢覆蓋掃描
o用戶登錄需要根據(jù)用戶名返回密碼用于驗證create index idx_uname_passwd on tb_user (username, password);
o建立聯(lián)合索引避免回表取數(shù)據(jù)
反范式，冗余必要字段
?針對核心SQL保留查詢結(jié)果所必須的冗余字段，避免頻繁join
o例：消息表中冗余了每次讀消息必須返回的nickname字段，避免每次讀消息都變成join操作。代價是用戶修改nickname成本變高。
拆分大字段
?拆分大字段到單獨(dú)表中，避免范圍掃描代價大
o例：博文表拆分兩份，標(biāo)題表只保留標(biāo)題和內(nèi)容縮略部分，用于快速批量返回標(biāo)題列表，正文表保存大段博文內(nèi)容，用于點(diǎn)開文章單個讀取
避免過多字段或過長行
?根據(jù)SQL必要返回設(shè)計字段，有必要就拆表，避免過多字段
?一次沒有必要獲取那么多列數(shù)據(jù)
?行過長導(dǎo)致表數(shù)據(jù)頁記錄變少，范圍掃描性能降低
?更新數(shù)據(jù)也代價增加
?16K也最少放2行，可能出現(xiàn)行遷移
分頁查詢
?避免limit + offset過大
?應(yīng)該使用自增主鍵ID模擬分頁
o第一頁，直接查
o得到第一頁的max(id)=123(一般是最后一條記錄)
o第二頁，帶上id>123查詢：where id>123 limit 100
o這樣每次只需要掃描100條數(shù)據(jù)
?要求業(yè)務(wù)上禁止查詢XX頁之后的數(shù)據(jù)
熱點(diǎn)讀數(shù)據(jù)特殊處理
?根據(jù)數(shù)據(jù)獲取的頻率或數(shù)量不同對熱點(diǎn)數(shù)據(jù)做特殊處理
o例1：論壇系統(tǒng)中置頂帖、公告貼，可以單獨(dú)拆分存儲，由于每次訪問都要全部讀出來，單獨(dú)放在一起，避免每次都到普通表中隨機(jī)找出來
熱點(diǎn)寫數(shù)據(jù)特殊處理
?根據(jù)數(shù)據(jù)獲取的頻率或數(shù)量不同對熱點(diǎn)數(shù)據(jù)做特殊處理
o例2：微博系統(tǒng)中對于大量關(guān)注的熱點(diǎn)賬號消息從"推"改為"拉"，避免過量insert操作。
準(zhǔn)實時統(tǒng)計
?對不需要精確結(jié)果的計數(shù)等統(tǒng)計要求，建立定期更新結(jié)果表
o例：首頁要求展示動態(tài)成交總金額，維護(hù)一個計數(shù)表，每分鐘根據(jù)原表注冊時間獲取增量sum值更新計數(shù)表，避免每次用戶刷新都要掃描交易全記錄表
實時統(tǒng)計改進(jìn)1 - 觸發(fā)器實時統(tǒng)計
?對需要精確統(tǒng)計的計數(shù)利用數(shù)據(jù)庫觸發(fā)器維護(hù)計數(shù)表
o例：用戶量沖億活動要求實時統(tǒng)計，用戶表上加觸發(fā)器，每次有新用戶插入就同時在計數(shù)表+1
實時統(tǒng)計改進(jìn)2 - 緩存實時統(tǒng)計
?對需要精確統(tǒng)計的計數(shù)利用前端緩存實時維護(hù)計數(shù)
o例：用戶量沖億活動要求實時統(tǒng)計，注冊數(shù)量在緩存中實時維護(hù)，每注冊一個就+1，完全避免數(shù)據(jù)庫讀寫操作。緩存萬一故障失效，可從數(shù)據(jù)庫整體count重新獲取。
實時統(tǒng)計改進(jìn)2 - 最大自增ID獲取總數(shù)
?很多邏輯可以利用自增ID主鍵最大值直接作為總數(shù)
o例：用戶量沖億活動要求實時統(tǒng)計，用戶表加上自增ID作為主鍵，只要取當(dāng)時max(ID)就可以得到用戶總數(shù)
課拓展性設(shè)計
?可拓展性
o硬件資源增長有極限的情況下處理盡可能久的線上業(yè)務(wù)
?數(shù)據(jù)分級，冷數(shù)據(jù)歸檔與淘汰
o可以不斷釋放空間供新數(shù)據(jù)使用
?為數(shù)據(jù)分布式做準(zhǔn)備
o分庫分表
o水平拆分
o犧牲一定的關(guān)系模型支持
分區(qū)表與數(shù)據(jù)淘汰
?range分區(qū)
?適合數(shù)據(jù)需要定期過期的大表
?單個分區(qū)掃描遷移數(shù)據(jù)到歷史庫避免全表掃描IO開銷
?刪除單個分區(qū)非常高效
分區(qū)表與垂直分區(qū)
?list分區(qū)
?適合將來可能要基于地區(qū)，類目等方式垂直拆分?jǐn)?shù)據(jù)的方式
?清理節(jié)點(diǎn)上不要的數(shù)據(jù)非常高效
分區(qū)表與水平分區(qū)
?hash分區(qū)
?適合將來需要做水平拆分的表
?清理節(jié)點(diǎn)上不要的數(shù)據(jù)非常高效
MySQL分區(qū)表的局限
?主鍵或唯一鍵必須包含在分區(qū)字段內(nèi)
?分區(qū)字段必須是整數(shù)類型，或者加上返回整數(shù)的函數(shù)
滿足周邊需求
?為周邊需求額外增加表設(shè)計
o為后臺統(tǒng)計任務(wù)增加特殊索引
o為數(shù)據(jù)遷移或統(tǒng)計需求增加時間戳
統(tǒng)計和后臺需求
?統(tǒng)計運(yùn)行SQL往往和線上有很大不同
o利用MySQL——主多從，主從可以建不同索引的特性將統(tǒng)計分流到特定從庫
o包括一些特殊用戶批量查詢等，所有對線上有IO壓力的查詢都要讀寫分離
自動更新時間戳
?統(tǒng)計需求經(jīng)常要求從線上讀走增量數(shù)據(jù)
?表的第一個timestamp類型字段再寫入時如果不填值，會自動寫入系統(tǒng)時間戳
?表的第一個timestamp類型字段每次記錄發(fā)生更新后都會自動更新
?在update_time字段上建索引用于定時導(dǎo)出增量數(shù)據(jù)
Schema設(shè)計與前瞻性
?基于歷史經(jīng)驗教訓(xùn)，預(yù)防和解決同類問題
?把折騰DBA夠嗆的所有Schema改造的原因記錄并分析總結(jié) 例：
?業(yè)務(wù)為例用戶信息加密做了大改造
o數(shù)據(jù)庫結(jié)果大量改動，增加了加密字段，驗證策略表，所有表重新訂正數(shù)據(jù)等等
o是否所有用到用戶信息管理的應(yīng)用都要去上線就用密文？
?程序bug誤刪數(shù)據(jù)，線上風(fēng)險大
o改造業(yè)務(wù)流程，不再刪除數(shù)據(jù)，加入is_deleted標(biāo)記位，經(jīng)常給各種表加
o今后的類似表是否一上線就都用標(biāo)記位的方式，并加上修改原因字段？
?支付類應(yīng)用后期做了風(fēng)控改造
o對線上訂單大表改造，加了限額，終端類型等字段
o遇到支付類應(yīng)用，是否一上線就提示業(yè)務(wù)是否需要考慮風(fēng)控并留好相關(guān)字段？
4.3-MySQL容量評估
性能容量評估
?分析線上業(yè)務(wù)場景
?評估數(shù)據(jù)庫服務(wù)器所需性能指標(biāo)
?預(yù)估可能成為瓶頸的服務(wù)器資源
?幫助數(shù)據(jù)庫性能調(diào)優(yōu)
數(shù)據(jù)庫服務(wù)器硬件性能指標(biāo)
?磁盤IO性能
?內(nèi)存容量
?CPU
?網(wǎng)絡(luò)吞吐量
?磁盤容量
數(shù)據(jù)庫業(yè)務(wù)特點(diǎn)關(guān)鍵詞
?OLTP/OLAP類型
?并發(fā)請求
?讀寫比例
?數(shù)據(jù)量
?冷熱數(shù)據(jù)比
?數(shù)據(jù)分級存儲
OLTP/OLAP
?T = Transaction
?面向廣大用戶，高并發(fā)，較短事務(wù)操作
?互聯(lián)網(wǎng)應(yīng)用絕大部分屬于OLTP
?OLTP看重服務(wù)器CPU，內(nèi)存，寫事務(wù)較多或內(nèi)存不夠則依賴磁盤IO
?A = Analytical
?通常面向內(nèi)部人員，大規(guī)模復(fù)查詢
?OLAP看重磁盤掃描的IO能力，部分依賴內(nèi)存排序
并發(fā)請求 - 衡量線上業(yè)務(wù)繁忙程度
?業(yè)務(wù)高峰時數(shù)據(jù)庫的每秒并發(fā)訪問量是多少
?通過應(yīng)用服務(wù)器數(shù)量，連接池配置判斷
?通過產(chǎn)品估算初上線用戶規(guī)模和用戶增長速度判斷
?通過實際業(yè)務(wù)業(yè)務(wù)類型判斷
?并發(fā)量相關(guān)資源：CPU
讀寫比例 - 描述應(yīng)用程序如何使用數(shù)據(jù)庫
?線上業(yè)務(wù)select只讀與update/delete/insert寫操作比例
?delete/update通常都是先讀再寫
?insert需要區(qū)分?jǐn)?shù)據(jù)寫入時持續(xù)insert還是大量導(dǎo)入數(shù)據(jù)
?根據(jù)業(yè)務(wù)實際場景分析
?多讀場景相關(guān)資源：內(nèi)存
?多寫場景相關(guān)資源：磁盤IO
數(shù)據(jù)量 - 總量
?數(shù)據(jù)庫服務(wù)器存儲設(shè)備可擴(kuò)容能力的上限
?根據(jù)估算的業(yè)務(wù)量，寫入模式，分析數(shù)據(jù)增長量
?預(yù)估一個硬件升級周期內(nèi)數(shù)據(jù)庫可存放數(shù)據(jù)的總量，上線時要留好余量
?數(shù)據(jù)總量相關(guān)資源：磁盤容量
冷數(shù)據(jù)與熱數(shù)據(jù) - 有用數(shù)據(jù)的實時集合
?熱數(shù)據(jù)，線上最新一定周期內(nèi)將被反復(fù)訪問的數(shù)據(jù)
?冷數(shù)據(jù)，線上保存著的，最近不會被在線用戶用到的數(shù)據(jù)
?估算活躍用戶量，數(shù)據(jù)增長量等預(yù)估熱數(shù)據(jù)量
?內(nèi)存大小盡可能足夠存放線上實時熱數(shù)據(jù)
?熱數(shù)據(jù)相關(guān)資源：內(nèi)存
線上數(shù)據(jù)分層存儲 - 緩解線上磁盤空間壓力
?最新熱數(shù)據(jù)確保放在內(nèi)存中
?還可能訪問到的較早數(shù)據(jù)存放在線上庫磁盤中
?更早的不會常規(guī)訪問的數(shù)據(jù)定期遷移至歷史庫中
?區(qū)分哪些數(shù)據(jù)時效性強(qiáng)可以遷移
服務(wù)器資源選型 - 將可選方案列出來
資源指標(biāo) 可選方案
磁盤IO性能 單盤 -> 盤陣; SATA -> SAS; HDD -> SSD
內(nèi)存容量 較小內(nèi)存 -> 較大內(nèi)存
CPU 普通 -> 多核，超線程
網(wǎng)絡(luò)吞吐量 千兆 -> 萬兆; 單網(wǎng)卡 -> 多路;
磁盤容量 單盤 -> 盤陣; 單盤 -> LVM
案例一，網(wǎng)易云音樂曲庫數(shù)據(jù)庫服務(wù)器評估
?用于存放線上數(shù)千萬歌曲信息
?確定屬于OLTP線上類型數(shù)據(jù)庫
?并發(fā)請求量
o50臺應(yīng)用服務(wù)器，每臺最大連接數(shù)100
o可能峰值5000qps，并發(fā)請求量較大
?CPU需求高
?讀寫比例
o訪問模式以用戶列出歌單和播放歌曲時查詢歌曲信息為主，用戶只有只讀查詢
o寫數(shù)據(jù)發(fā)生在錄入新歌或修改歌曲信息時后臺操作，寫比例小，且為批量導(dǎo)入
o讀寫比100:1
?數(shù)據(jù)總量
o估算每首歌信息8K，總計5000萬，總量400G
o數(shù)據(jù)總量增長相對緩慢
?冷熱數(shù)據(jù)
o5000萬歌曲中大約40%可能被訪問，10%屬于熱點(diǎn)歌曲
o熱數(shù)據(jù)大約<=40G
?數(shù)據(jù)分級存儲需求
o由于沒有用戶產(chǎn)生的數(shù)據(jù)，歌曲信息無法分級存儲
?內(nèi)存需求一般，>=40G
?磁盤IO能力需求一般
?網(wǎng)絡(luò)流量要求，8k*2500/1024 ≈ 20MB/S，一般
資源指標(biāo) 可選方案
磁盤IO性能 兩塊SAS做RAID1
內(nèi)存容量 96G內(nèi)存
CPU 2c8core超線程 相當(dāng)于32核
網(wǎng)絡(luò)吞吐量 千兆雙網(wǎng)卡bunding
磁盤容量 900G
案例二，網(wǎng)易理財銷售數(shù)據(jù)庫服務(wù)器評估
?用于存放理財用戶線上訂單
?確定屬于OLTP線上類型數(shù)據(jù)庫
?業(yè)務(wù)場景有明顯特征
o特定高息產(chǎn)品秒殺銷售時間窗有大量并發(fā)訂單寫入
o平時只有少量訂單查詢和請求，和較低的常規(guī)產(chǎn)品購買請求
?評估應(yīng)以滿足最關(guān)鍵的業(yè)務(wù)高峰為基準(zhǔn)
?并發(fā)請求量
o秒殺期間持續(xù)時間短，但是并發(fā)量預(yù)估30臺應(yīng)用服務(wù)器約2000tps
?讀寫比例
o高峰時寫訂單是主要開銷操作
?CPU要求高
?磁盤IO要求很高
?數(shù)據(jù)總量
o根據(jù)業(yè)務(wù)分析，訂單屬于寫入瞬時量大，總量較小，單筆金額較高
o總量預(yù)估一年成交百萬級別，增長較穩(wěn)定
o判斷數(shù)據(jù)存儲需求小于200G
?冷熱數(shù)據(jù)
o峰值寫入為主，內(nèi)存要求存放熱點(diǎn)期間產(chǎn)生的臟數(shù)據(jù)即可
?數(shù)據(jù)分級存儲需求
o用戶訂單業(yè)務(wù)約定頁面展示最近半年訂單，半年前的需要到歷史查詢頁面專門查詢
o因此可以做分級存儲，遷移所有半年前的訂單至歷史庫
?內(nèi)存需求一般， >= 30G
?磁盤空間需求一般， >=200G
?磁盤IO能力需求很高
?網(wǎng)絡(luò)要求較高
o并發(fā)流量較高
o響應(yīng)速度要求高
資源指標(biāo) 可選方案
磁盤IO性能 兩塊SSD做RAID1
內(nèi)存容量 64G內(nèi)存
CPU 2c8core超線程 相當(dāng)于32核
網(wǎng)絡(luò)吞吐量 萬兆雙網(wǎng)卡bunding
磁盤容量 600G
4.4-MySQL性能測試
為什么需要性能測試
?對線上產(chǎn)品缺乏心理預(yù)估
?重現(xiàn)線上異常
?規(guī)劃未來的業(yè)務(wù)增長
?測試不同硬件軟件配置
性能測試的分類
?設(shè)備層的測試
?業(yè)務(wù)層的測試
?數(shù)據(jù)庫層的測試
設(shè)備層的測試
?關(guān)注的指標(biāo)
o服務(wù)器、磁盤性能
o磁盤壞塊率
o服務(wù)器壽命
業(yè)務(wù)層測試
?針對業(yè)務(wù)進(jìn)行測試
數(shù)據(jù)庫層測試
?什么情況下要做MySQL的測試
o測試不同的MySQL分支版本
o測試不同的MySQL版本
o測試不同的MySQL參數(shù)搭配
MySQL測試分類
?CPU Bound
?IO Bound
寫入測試 更新測試 純讀測試 混合模式
常用的測試工具
?開源的MySQL性能測試工具
osysbench
otpcc-mysql
omysqlslap
?針對業(yè)務(wù)編寫性能測試工具
oblogbench
性能測試衡量指標(biāo)
?服務(wù)吞吐量(TPS, QPS)
?服務(wù)響應(yīng)時間
?服務(wù)并發(fā)性
Sysbench
?業(yè)界較為出名的性能測試工具
?可以測試磁盤、CPU、數(shù)據(jù)庫
?支持多種數(shù)據(jù)庫：Oracle, DB2, MySQL
?需要自己下載編譯安裝
?建議版本：sysbench0.5
編譯安裝Sysbench
?下載sysbench
ogit clone https://github.com/akopytov/sysbench.git
?編譯&安裝
o./autogen.sh
o./configure
omake && make install
Sysbench流程
?常見的做法
初始化數(shù)據(jù) -> 運(yùn)行測試 -> 清理數(shù)據(jù)
Prepare語法
sysbench --test=parallel_prepare.lua --oltp_tables_count=1 --rand-init=on --oltp-table-size=500000000 --mysql-host=127.0.0.1 --mysql-port=3306 --mysql-user=sys --mysql-password=netease --mysql-db=sbtest --max-requests=0 prepare
參數(shù) 含義
--test=parallel_prepare.lua 運(yùn)行導(dǎo)數(shù)據(jù)的腳本
--oltp_tables_count 測試需要幾張表
--oltp-table-size 每張表的大小
--mysql-host MySQL Host
--mysql-port MySQL Port
--mysql-db MySQL DB
--mysql-user MySQL User
--mysql-password MySQL Password
--rand-init 是否隨機(jī)初始化數(shù)據(jù)
--max-requests 執(zhí)行多少個請求之后停止
prepare 執(zhí)行導(dǎo)數(shù)據(jù)
Sysbench表結(jié)構(gòu)
create table 'sbtest1'(
'id' int(10) unsigned not null AUTO_INCREMENT,
'k' int(10) unsigned not null DEFAULT '0',
'c' char(120) not null DEFAULT '',
'pad' char(60) not null DEFAULT '',
PRIMARY KEY ('id'),
KEY 'k_1' ('k')
) ENGINE=InnoDB AUTO_INCREMENT=3000000001 DEFAULT CHARSET=utf8 MAX_ROWS=1000000
Run語法
sysbench --test=oltp.lua --oltp_tables_count=1 --num-threads=100 --oltp-table-size=500000000 --oltp-read-only=off --report-interval=10 --rand-type=uniform --mysql-host=127.0.0.1 --mysql-port=3306 --mysql-user=sys --mysql-password=netease --mysql-db=sbtest --max-time=1000 --max-requests=0 run
參數(shù) 含義
--test=oltp.lua 需要運(yùn)行的lua腳本
--oltp_tables_count 測試需要幾張表
--oltp-table-size 每張表的大小
--num-threads 測試并發(fā)線程數(shù)
--oltp-read-only 是否為只讀測試
--report-interval 結(jié)果輸出間隔
--rand-type 數(shù)據(jù)分布模式，熱點(diǎn)數(shù)據(jù)或者隨機(jī)數(shù)據(jù)
--max-time 最大運(yùn)行時間
--max-requests 執(zhí)行多少個請求之后停止
prepare 開始測試
特殊情況
?寫入測試
寫入數(shù)據(jù)進(jìn)行測試 -> 清理數(shù)據(jù)
cleanup
?手動drop掉表和database
?使用sysbench提供的cleanup命令
sysbench --test=parallel_prepare.lua --oltp_tables_count=1 --rand-init=on --oltp-table-size=500000000 --mysql-host=127.0.0.1 --mysql-port=3306 --mysql-user=sys --mysql-password=netease --mysql-db=sbtest --max-requests=0 cleanup
Tpcc-mysql
?
TPC-C是專門針對聯(lián)機(jī)交易處理系統(tǒng)(OLTP系統(tǒng))的規(guī)范
?
?
Tpcc-mysql由percona根據(jù)規(guī)范實現(xiàn)
?
?
下載Tpcc-mysql
?
obzr branch lp:~percona-dev/perconatools/tpcc-mysql
?
編譯安裝
?
使用Tpcc-mysql的步驟
創(chuàng)建表結(jié)構(gòu)和索引 -> 導(dǎo)數(shù)據(jù) -> 運(yùn)行測試 -> 數(shù)據(jù)清理
創(chuàng)建表結(jié)構(gòu)
?create_table.sql
?add_fkey_idx.sql
Tpcc-load
tpcc_load [server] [DB] [user] [pass] [warehouse]
函數(shù) 含義
server 數(shù)據(jù)庫IP
DB DB名稱
user 用戶名
pass 密碼
warehouse 倉庫數(shù)量
Tpcc-start
tpcc_start -h server_host -P port -d database_name -u mysql_user -p mysql_password -w warehouse -c connections -r warmup_time -I running_time -i report-interval -f report-file
函數(shù) 含義
warehouse 倉庫數(shù)量
connections 并發(fā)線程數(shù)
warmup_time 預(yù)熱時間
running_time 運(yùn)行時間
report_interval 輸出時間間隔
report_file 輸出文件
總結(jié)
?IO Bound測試數(shù)據(jù)量要遠(yuǎn)大于內(nèi)存、CPU Bound測試數(shù)據(jù)量要小于內(nèi)存
?測試時間建議大于60分鐘，減小誤差
?Sysbench更傾向于測試MySQL性能、TPCC更接近于業(yè)務(wù)
?運(yùn)行測試程序需要同時監(jiān)控機(jī)器負(fù)載，MySQL各項監(jiān)控指標(biāo)

10年積累的網(wǎng)站制作、成都網(wǎng)站制作經(jīng)驗，可以快速應(yīng)對客戶對網(wǎng)站的新想法和需求。提供各種問題對應(yīng)的解決方案。讓選擇我們的客戶得到更好、更有力的網(wǎng)絡(luò)服務(wù)。我雖然不認(rèn)識你，你也不認(rèn)識我。但先網(wǎng)站設(shè)計后付款的網(wǎng)站建設(shè)流程，更有項城免費(fèi)網(wǎng)站建設(shè)讓你可以放心的選擇與我們合作。

分享名稱：MYSQL數(shù)據(jù)庫學(xué)習(xí)系列四
文章轉(zhuǎn)載：http://muchs.cn/article38/jpissp.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供小程序開發(fā)、服務(wù)器托管、企業(yè)網(wǎng)站制作、靜態(tài)網(wǎng)站、網(wǎng)站改版、Google

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)