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