這幾天在review公司項(xiàng)目mysql這塊的架構(gòu)，網(wǎng)上google出來(lái)的東西大多是皮毛（特別一些中文站點(diǎn)里的，英文的話(huà)閱讀和消化都比較慢，除非不得已），有些還明顯有些錯(cuò)誤。
之前看《Http權(quán)威指南》的甜頭還在（加上有些積累現(xiàn)在看技術(shù)書(shū)速度也快了），所以趕緊找些質(zhì)量高的mysql方面的書(shū)看，找到一本阿里人寫(xiě)的《Mysql性能調(diào)優(yōu)與架構(gòu)設(shè)計(jì)》，F(xiàn)enng也有做序推薦。
正文部分為閱讀筆記。
二、硬件關(guān)鍵指標(biāo) 下邊列出是常見(jiàn)性能指標(biāo)，具體指標(biāo)的取舍也要看具體應(yīng)用場(chǎng)景。具體設(shè)計(jì)時(shí)再回頭參考書(shū)里里講的例子。
1.IO性能高的部件主要由磁盤(pán)和內(nèi)存，各種與IO相關(guān)的板卡相關(guān)。
IO性能分為和IOPS（每秒可提供的IO訪(fǎng)問(wèn)次數(shù)）和每秒的IO總流量（IO吞吐量）。
2.CPU（SQL parse和優(yōu)化），并發(fā)高的時(shí)候CPU每秒需要處理的請(qǐng)求就高，相應(yīng)CPU處理能力需要比較強(qiáng)勁。
3.網(wǎng)絡(luò)設(shè)備
二、性能優(yōu)化
（一）商業(yè)需求合理化
書(shū)里例子：實(shí)時(shí)更新一個(gè)論壇帖子總量的統(tǒng)計(jì)。
select count(*)語(yǔ)句簡(jiǎn)單，但是Innodb引擎還是耗時(shí)間。而這個(gè)需求的強(qiáng)實(shí)時(shí)更新沒(méi)多少用戶(hù)真正關(guān)心這個(gè)。定時(shí)更新可提高很大的性能。
這條自己已經(jīng)知道了。
（二）系統(tǒng)架構(gòu)最優(yōu)化
（1）有幾類(lèi)數(shù)據(jù)不適合存到數(shù)據(jù)庫(kù)中：
1.二進(jìn)制多媒體數(shù)據(jù)（圖片、音頻、視頻等），這類(lèi)數(shù)據(jù)對(duì)數(shù)據(jù)庫(kù)空間資源耗費(fèi)非常嚴(yán)重，且這些數(shù)據(jù)的數(shù)據(jù)存儲(chǔ)很消耗數(shù)據(jù)庫(kù)主機(jī)的CPU資源。
2.流水隊(duì)列數(shù)據(jù)，支持事務(wù)的存儲(chǔ)引擎為了事務(wù)安全性和可恢復(fù)性，需要記錄所有變更的日志信息，而流水隊(duì)列數(shù)據(jù)會(huì)不斷的被INSERT\UPDATE\DELETE，導(dǎo)致日志量很大。使用成熟的第三方隊(duì)列軟件處理，性能將會(huì)成倍提升。
3.超大文本數(shù)據(jù)，從5.0.3開(kāi)始，VARCHAR，實(shí)際數(shù)據(jù)小于255字節(jié)時(shí)，實(shí)際存儲(chǔ)空間和實(shí)際數(shù)據(jù)長(zhǎng)度一樣，可一旦長(zhǎng)度超過(guò)255字節(jié)之后，所占用存儲(chǔ)空間是實(shí)際數(shù)據(jù)長(zhǎng)度的兩倍。不光性能低下，還是浪費(fèi)空間。
（2）是否合理利用了應(yīng)用層的cache。
（3）數(shù)據(jù)層的存取實(shí)現(xiàn)都是最精簡(jiǎn)的嗎。在程序里不要過(guò)度依賴(lài)面向?qū)ο笏枷搿?/div>
（4）過(guò)度依賴(lài)數(shù)據(jù)庫(kù)SQL語(yǔ)句的功能造成數(shù)據(jù)庫(kù)操作效率低下。
盡量減少與mysql的交互次數(shù)和SQL復(fù)雜度。不要對(duì)可擴(kuò)展性過(guò)度追求，導(dǎo)致系統(tǒng)設(shè)計(jì)時(shí)開(kāi)分太李三，導(dǎo)致需要大量Join語(yǔ)句。
（5）重復(fù)執(zhí)行相同的SQL造成資源浪費(fèi)。
（三）邏輯實(shí)現(xiàn)精簡(jiǎn)化
（四）硬件設(shè)施理性化
三、合理利用鎖機(jī)制來(lái)優(yōu)化mysql
四、Query優(yōu)化
主要優(yōu)化思路和原則：
（1）優(yōu)化更需要優(yōu)化的Query。
（2）定位優(yōu)化對(duì)象的性能瓶頸。
（3）明確的優(yōu)化目標(biāo)。
（4）從explain入手。
（5）多使用profile。
（6）永遠(yuǎn)用小結(jié)果集驅(qū)動(dòng)大的結(jié)果集。
（7）盡可能在索引中完成排序。
（8）只取出自己需要的columns。
（9）僅僅使用最有效的過(guò)濾條件。
（10）盡可能避免復(fù)雜的join和子查詢(xún)。
五、Schema設(shè)計(jì)的性能優(yōu)化
（一）高校的模型設(shè)計(jì)
（1）不一定要追求范式
（2）適度冗余——讓query盡量減少join。
（3）大字段垂直分拆
字段特別大，訪(fǎng)問(wèn)頻率又很低的字段拆出去。因?yàn)橛涗洿鎯?chǔ)是一條一條的存放，查詢(xún)某些數(shù)據(jù)時(shí)，也會(huì)讀取到這個(gè)訪(fǎng)問(wèn)不高的大字段，比較浪費(fèi)IO資源。
（4）大表水平分拆——基于類(lèi)型的分拆優(yōu)化
把少量訪(fǎng)問(wèn)頻率極高的記錄水平拆分出去。例如論壇里的置頂帖子從普通討論貼里分拆出去為單獨(dú)的表。
（5）統(tǒng)計(jì)表——準(zhǔn)實(shí)時(shí)優(yōu)化
（二）合適的數(shù)據(jù)類(lèi)型
選擇更小的數(shù)據(jù)類(lèi)型，可以降低IO消耗。另外不同數(shù)據(jù)類(lèi)型的CPU處理方式也不一樣。例如通過(guò)整數(shù)類(lèi)型代替浮點(diǎn)數(shù)或者字符類(lèi)型。
（三）規(guī)范的對(duì)象命名
這條對(duì)性能沒(méi)啥影響，但是對(duì)數(shù)據(jù)庫(kù)的維護(hù)影響非常大。庫(kù)的字段越來(lái)越多……
六、mysql server性能優(yōu)化
七、存儲(chǔ)引擎優(yōu)化
八、架構(gòu)設(shè)計(jì)
（一）可擴(kuò)展設(shè)計(jì)的基本原則
（二）mysql replication
（三）數(shù)據(jù)切分
水平切分和垂直切分，之前項(xiàng)目里做架構(gòu)時(shí)已基本了解。
（四）cache和search的利用
cache就是memcache之類(lèi)的。search主要用來(lái)做全文檢索。
（五）mysql cluster
（六）高可用設(shè)計(jì)之思路及方案
（七）高可用設(shè)計(jì)之mysql監(jiān)控
看完上邊后又在看《高性能mysql》第三版2013年初版的，美國(guó)人寫(xiě)的，這本是mysql的經(jīng)典之作，比上邊那本更好吧。就是內(nèi)容詳細(xì)，啥都有。詳細(xì)的基準(zhǔn)測(cè)試方法、特性細(xì)節(jié)（原理）、架構(gòu)考慮，這幾年mysql升級(jí)的特性（如分區(qū)等），講述的mysql版本已經(jīng)新到5.5~稍許5.6前瞻。還有作者都是相關(guān)經(jīng)驗(yàn)很多年的大拿。內(nèi)容寫(xiě)的也不枯燥，很向那些編程方面的經(jīng)典書(shū)的書(shū)寫(xiě)風(fēng)格。 時(shí)間寶貴，推薦看《高性能mysql》這本就行了。