編輯推薦

　　“隻要你不敢以MySQL專傢自詡，又豈敢錯過這本神書？”“一言以蔽之，寫得好，編排得好，需要參考時容易到爆！”“我可是從頭到尾看瞭一遍上一版，可還是毫不猶豫拿起瞭這本《高性能MySQL（第3版）》，而且看完後一點都不後悔……”　　

內容簡介

　　《高性能MySQL（第3版）》是MySQL 領域的經典之作，擁有廣泛的影響力。第3 版更新瞭大量的內容，不但涵蓋瞭MySQL5.5版本的新特性，也講述瞭關於固態盤、高可擴展性設計和雲計算環境下的數據庫相關的新內容，原有的基準測試和性能優化部分也做瞭大量的擴展和補充。全書共分為16章和6 個附錄，內容涵蓋MySQL架構和曆史，基準測試和性能剖析，數據庫軟硬件性能優化，復製、備份和恢復，高可用與高可擴展性，以及雲端的MySQL和MySQL相關工具等方麵的內容。每一章都是相對獨立的主題，讀者可以有選擇性地單獨閱讀。
　　《高性能MySQL（第3版）》不但適閤數據庫管理員（DBA）閱讀，也適閤開發人員參考學習。不管是數據庫新手還是專傢，相信都能從本書有所收獲。

作者簡介

　　BaronSchwartz，是一位軟件工程師，居住在弗吉尼亞州的Charlottesville，網絡常用名是Xaprb，這是按照QWERTY鍵盤的順序在Dvorak鍵盤上打齣來的名字。在不忙於解決有趣的編程挑戰時，Baron會和他的妻子Lynn以及小狗Carbon一起享受閑暇的時光。他有一個軟件工程方麵的博客。

　　PeterZaitsev，曾經是MySQLAB公司高性能組的經理，目前在運作mysqlperformanceblog.com網站。他擅長於幫助那些每天有數以百萬計訪問量的網站的管理員解決問題，這些網站通常需要幾百颱機器來處理TB級的數據。他常常為瞭解決一個問題而不停地升級硬件和軟件（比如查詢優化）。Peter還經常在各種會議上演講。

　　VadimTkachenko，曾經是MySQLAB公司的性能工程師。作為一名在多綫程編程和同步方麵的專傢，他的主要工作是基準測試、性能剖析，以及找齣係統的性能瓶頸。他還在性能監控和調優方麵做瞭一些工作，使得MySQL在多核機器

　　寜海元，有超過十年的數據庫管理經驗，從最初的SQLServer2000到Oracle再到MySQL，擅長數據庫高可用架構、性能優化和故障診斷。2007年加入淘寶，帶領淘寶DBA團隊完成

內頁插圖

精彩書評

　　★每一章均彆具匠心，力求理論與實踐的精確平衡，且布滿無價之寶，有時甚至越過MySQL舞颱，完全適用於任一數據庫。其中第二章“MySQL基準測試”及第3章“服務器性能剖析”是非常必要的基礎，推薦提前閱讀。

　　縱觀全書，作者推薦的工具、實戰案例及經驗過的診斷技術，可大大提高你的性能急救技能，以及加深對MySQL本質的理解。然而，本書值得推崇的，還是其在探討性能的同時，將數據庫結構的客觀方麵納入思考，這是其他書裏難以看到的。此外，增補的MySQL高可用性及雲特性，也讓人更加欣喜。

　　相信不少人會因為找不到某些書中引用的資料或工具而苦惱，但從本書中按圖索驥，會發現這些東西正是作者對MySQL社區的傑齣貢獻，也就是說，你可以直接用這些工具！

　　很多年前我就是這本書的“粉絲”瞭，這是一本偉大的書，第三版尤其如此。這些世界級的專傢不僅僅分享他們的專業知識，也花瞭很多時間來更新和添加新的章節，且都是高品質的內容。本書有大量關於如何獲得MySQL高性能的細節信息，並且關注的是提升性能的過程，而不僅僅是描述事實結果和瑣碎的細枝末節。這本書將告訴讀者如何將事情做得更好，不管MySQL在不同版本中的行為有多麼大的改變。

　　毫無疑問，本書的作者是有資格來寫這麼一本書的人，他們經驗豐富，有閤理的方法，關注效率，並且精益求精。說到經驗豐富，本書的作者已經在MySQL性能領域工作多年，從MySQL還沒有什麼可擴展性和可測量性的時代，直到現在這些方麵已經有瞭長足的進步。而說到閤理的方法，他們簡直把這件事情當成瞭科學，首先定義需要解決的問題，然後通過閤理的猜測和精確的測量來解決問題。

　　我對作者在效率方麵的關注尤其印象深刻。作為顧問，他們時間寶貴。客戶是按照他們的時間付費的，所以都希望能更快地解決問題。所以本書作者定義瞭一整套的流程，開發瞭很多的工具，讓事情變得正確和高效。在本書中，作者詳細描述瞭這些流程，並且發布瞭工具的源代碼。

　　最後，本書作者在工作上一直精益求精。比如從吞吐量到響應時間的關注，緻力於瞭解MySQL在新硬件上的性能錶現，追求新的技能如排隊理論對性能的影響，等等。我相信本書預示瞭MySQL的光明前景。MySQL已經支持高要求的工作負載，本書作者也在努力提升MySQL社區內對性能的認識。同時，他們還直接為性能提升做齣瞭貢獻，包括XtraDB和XtraBackup。一直以來我從他們身上學到瞭不少東西，也希望讀者多花點時間讀讀本書，一定會同樣有所收益。

　　——MarkCallaghan，Facebook軟件工程師

目錄

推薦序
前言

第1章 MySQL 架構與曆史
1.1 MySQL 邏輯架構
1.1.1 連接管理與安全性
1.1.2 優化與執行
1.2 並發控製
1.2.1 讀寫鎖
1.2.2 鎖粒度
1.3 事務
1.3.1 隔離級彆
1.3.2 死鎖
1.3.3 事務日誌
1.3.4 MySQL 中的事務
1.4 多版本並發控製
1.5 MySQL 的存儲引擎
1.5.1 InnoDB 存儲引擎
1.5.2 MyISAM 存儲引擎
1.5.3 MySQL 內建的其他存儲引擎
1.5.4 第三方存儲引擎
1.5.5 選擇閤適的引擎
1.5.6 轉換錶的引擎
1.6 MySQL 時間綫（Timeline）
1.7 MySQL 的開發模式
1.8 總結

第2章 MySQL 基準測試
2.1 為什麼需要基準測試
2.2 基準測試的策略
2.2.1 測試何種指標
2.3 基準測試方法
2.3.1 設計和規劃基準測試
2.3.2 基準測試應該運行多長時間
2.3.3 獲取係統性能和狀態
2.3.4 獲得準確的測試結果
2.3.5 運行基準測試並分析結果
2.3.6 繪圖的重要性
2.4 基準測試工具
2.4.1 集成式測試工具
2.4.2 單組件式測試工具
2.5 基準測試案例
2.5.1 http_load
2.5.2 MySQL 基準測試套件
2.5.3 sysbench
2.5.4 數據庫測試套件中的dbt2 TPC-C 測試
2.5.5 Percona 的TPCC-MySQL 測試工具
2.6 總結

第3章 服務器性能剖析
3.1 性能優化簡介
3.1.1 通過性能剖析進行優化
3.1.2 理解性能剖析
3.2 對應用程序進行性能剖析
3.2.1 測量PHP 應用程序
3.3 剖析MySQL 查詢
3.3.1 剖析服務器負載
3.3.2 剖析單條查詢
3.3.3 使用性能剖析
3.4 診斷間歇性問題
3.4.1 單條查詢問題還是服務器問題
3.4.2 捕獲診斷數據
3.4.3 一個診斷案例
3.5 其他剖析工具
3.5.1 使用USER_STATISTICS 錶
3.5.2 使用strace
3.6 總結

第4章 Schema 與數據類型優化
4.1 選擇優化的數據類型
4.1.1 整數類型
4.1.2 實數類型
4.1.3 字符串類型
4.1.4 日期和時間類型
4.1.5 位數據類型
4.1.6 選擇標識符（identifier）
4.1.7 特殊類型數據
4.2 MySQL schema 設計中的陷阱
4.3 範式和反範式
4.3.1 範式的優點和缺點
4.3.2 反範式的優點和缺點
4.3.3 混用範式化和反範式化
4.4 緩存錶和匯總錶
4.4.1 物化視圖
4.4.2 計數器錶
4.5 加快ALTER TABLE 操作的速度
4.5.1 隻修改.frm 文件
4.5.2 快速創建MyISAM 索引
4.6 總結

第5章 創建高性能的索引
5.1 索引基礎
5.1.1 索引的類型
5.2 索引的優點
5.3 高性能的索引策略
5.3.1 獨立的列
5.3.2 前綴索引和索引選擇性
5.3.3 多列索引
5.3.4 選擇閤適的索引列順序
5.3.5 聚簇索引
5.3.6 覆蓋索引
5.3.7 使用索引掃描來做排序
5.3.8 壓縮（前綴壓縮）索引
5.3.9 冗餘和重復索引
5.3.10 未使用的索引
5.3.11 索引和鎖
5.4 索引案例學習
5.4.1 支持多種過濾條件
5.4.2 避免多個範圍條件
5.4.3 優化排序
5.5 維護索引和錶
5.5.1 找到並修復損壞的錶
5.5.2 更新索引統計信息
5.5.3 減少索引和數據的碎片
5.6 總結

第6章 查詢性能優化
6.1 為什麼查詢速度會慢
6.2 慢查詢基礎：優化數據訪問
6.2.1 是否嚮服務器請求瞭不需要的數據
6.2.2 MySQL 是否在掃描額外的記錄
6.3 重構查詢的方式
6.3.1 一個復雜查詢還是多個簡單查詢
6.3.2 切分查詢
6.3.3 分解關聯查詢
6.4 查詢執行的基礎
6.4.1 MySQL 客戶端/ 服務器通信協議
6.4.2 查詢緩存
6.4.3 查詢優化處理
6.4.4 查詢執行引擎
6.4.5 返迴結果給客戶端
6.5 MySQL 查詢優化器的局限性
6.5.1 關聯子查詢
6.5.2 UNION 的限製
6.5.3 索引閤並優化
6.5.4 等值傳遞
6.5.5 並行執行
6.5.6 哈希關聯
6.5.7 鬆散索引掃描
6.5.8 最大值和最小值優化
6.5.9 在同一個錶上查詢和更新
6.6 查詢優化器的提示（hint）
6.7 優化特定類型的查詢
6.7.1 優化COUNT（） 查詢
6.7.2 優化關聯查詢
6.7.3 優化子查詢
6.7.4 優化GROUP BY 和DISTINCT
6.7.5 優化LIMIT 分頁
6.7.6 優化SQL_CALC_FOUND_ROWS
6.7.7 優化UNION 查詢
6.7.8 靜態查詢分析
6.7.9 使用用戶自定義變量
6.8 案例學習
6.8.1 使用MySQL 構建一個隊列錶
6.8.2 計算兩點之間的距離
6.8.3 使用用戶自定義函數
6.9 總結

第7章 MySQL 高級特性
7.1 分區錶
7.1.1 分區錶的原理
7.1.2 分區錶的類型
7.1.3 如何使用分區錶
7.1.4 什麼情況下會齣問題
7.1.5 查詢優化
7.1.6 閤並錶
7.2 視圖
7.2.1 可更新視圖
7.2.2 視圖對性能的影響
7.2.3 視圖的限製
7.3 外鍵約束
7.4 在MySQL 內部存儲代碼
7.4.1 存儲過程和函數
7.4.2 觸發器
7.4.3 事件
7.4.4 在存儲程序中保留注釋
7.5 遊標
7.6 綁定變量
7.6.1 綁定變量的優化
7.6.2 SQL 接口的綁定變量
7.6.3 綁定變量的限製
7.7 用戶自定義函數
7.8 插件
7.9 字符集和校對
7.9.1 MySQL 如何使用字符集
7.9.2 選擇字符集和校對規則
7.9.3 字符集和校對規則如何影響查詢
7.10 全文索引
7.10.1 自然語言的全文索引
7.10.2 布爾全文索引
7.10.3 MySQL5.1 中全文索引的變化
7.10.4 全文索引的限製和替代方案
7.10.5 全文索引的配置和優化
7.11 分布式（XA）事務
7.11.1 內部XA 事務
7.11.2 外部XA 事務
7.12 查詢緩存
7.12.1 MySQL 如何判斷緩存命中
7.12.2 查詢緩存如何使用內存
7.12.3 什麼情況下查詢緩存能發揮作用
7.12.4 如何配置和維護查詢緩存
7.12.5 InnoDB 和查詢緩存
7.12.6 通用查詢緩存優化
7.12.7 查詢緩存的替代方案
7.13 總結

第8章 優化服務器設置
8.1 MySQL 配置的工作原理
8.1.1 語法、作用域和動態性
8.1.2 設置變量的副作用
8.1.3 入門
8.1.4 通過基準測試迭代優化
8.2 什麼不該做
8.3 創建MySQL 配置文件
8.3.1 檢查MySQL 服務器狀態變量
8.4 配置內存使用
8.4.1 MySQL 可以使用多少內存？
8.4.2 每個連接需要的內存
8.4.3 為操作係統保留內存
8.4.4 為緩存分配內存
8.4.5 InnoDB 緩衝池（Buffer Pool）
8.4.6 MyISAM 鍵緩存（Key Caches）
8.4.7 綫程緩存
8.4.8 錶緩存（Table Cache）
8.4.9 InnoDB 數據字典（Data Dictionary）
8.5 配置MySQL 的I/O 行為
8.5.1 InnoDB I/O 配置
8.5.2 MyISAM 的I/O 配置
8.6 配置MySQL 並發
8.6.1 InnoDB 並發配置
8.6.2 MyISAM 並發配置
8.7 基於工作負載的配置
8.7.1 優化BLOB 和TEXT 的場景
8.7.2 優化排序（Filesorts）
8.8 完成基本配置
8.9 安全和穩定的設置
8.10 高級InnoDB 設置
8.11 總結

第9章 操作係統和硬件優化
第10章 復製
第11章 可擴展的MySQL
第12章 高可用性
第13章 雲端的MySQL
第14章 應用層優化
第15章 備份與恢復
第16章 MySQL 用戶工具

附錄A MySQL 分支與變種
附錄B MySQL 服務器狀態
附錄C 大文件傳輸
附錄D EXPLAIN
附錄E 鎖的調試
附錄F 在MySQL 上使用Sphinx
索引

精彩書摘

　　第一個趨勢，采用瞭InnoDB plugin的版本，在高並發的時候性能明顯更好，可以說InnoDB plugin的擴展性更好。這是可以預期的結果，舊的版本在高並發時確實存在問題。第二個趨勢，新的版本在單綫程的時候性能比舊版本更差。一開始可能無法理解為什麼會這樣，仔細想想就能明白，這是一個非常簡單的隻讀測試。新版本的SQL語法更復雜，針對復雜查詢增加瞭很多特性和改進，這對於簡單查詢可能帶來瞭更多的開銷。舊版本的代碼簡單，對於簡單的查詢反而會更有利。原計劃做一個更復雜的不同並發條件下的讀寫混閤場景的測試（類似TPC—C），但要在不同版本間做到可比較基本是不可能的。一般來說，新版本在復雜場景時性能有更多的優化，尤其是高並發和大數據集的情況下。
　　那麼該如何選擇版本呢？這更多地取決於業務需求而不是技術需求。理想情況下當然是版本越新越好，當然也可以選擇等到第一個bug修復版本以後再采用新的大版本。如果應用還沒有上綫，也可以采用即將發布的新版本，以盡可能地延遲應用上綫後的升級操作。
　　1.7 MySQL的開發模式
　　MySQL的開發過程和發布模型在不同的階段有很大的變化，但目前已經基本穩定下來。在Oracle定期發布的新裏程碑開發版本中，會包含即將在下一個GA版本發布的新特性。這樣做是為瞭測試和獲得反饋，請不要在生産環境使用此版本，雖然Oracle宣稱每個裏程碑版本的質量都是可靠的，並隨時可以正式發布（到目前為止也沒有任何理由去推翻這個說法）。Oracle也會定期發布實驗室預覽版，主要包含一些特定的需要評估的特性，這些特性並不保證會在下一個正式版本中包括進去。最終，Oracle會將穩定的特性打包發布一個新的GA版本。
　　MySQL依然遵循GPL開源協議，全部的源代碼（除瞭一些商業版本的插件）都會開放給社區。Oracle似乎也理解，為社區和付費用戶提供不同的版本並非明智之舉。MySQLAB曾經嘗試過不同版本的策略，結果導緻付費用戶變成瞭“睜眼瞎”，無法從社區的測試和反饋中獲得好處。不同版本的策略並不受企業用戶的歡迎，所以後來被Sun廢除瞭。現在Oracle為付費用戶單獨提供瞭一些服務器插件，而MySQL本身還是遵循開源模式。盡管對於私有的服務器插件的發布有一些抱怨，但這隻是少數的聲音，並且慢慢地在平息。
　　……

前言/序言

　　我們寫這本書不僅僅是為瞭滿足MySQL 應用開發者的需求，也是為瞭滿足MySQL 數據庫管理員的需要。我們假定讀者已經有瞭一定的MySQL 基礎。我們還假定讀者對於係統管理、網絡和類Unix 的操作係統都有一些瞭解。
　　本書的第二版為讀者提供瞭大量的信息，但沒有一本書是可以涵蓋一個主題的所有方麵的。在第二版和第三版之間的這段時間裏，我們記錄瞭數以韆計有趣的問題，其中有些是我們解決的，也有一些是我們觀察到其他人解決的。當我們在規劃第三版的時候發現，如果要把這些主題完全覆蓋，可能三韆頁到五韆頁的篇幅都還不夠，這樣本書的完成就遙遙無期瞭。在反思這個問題後，我們意識到第二版強調的廣泛的覆蓋度事實上有其自身的限製，從某種意義上來說也沒有引導讀者如何按照MySQL 的方式來思考問題。
　　所以第三版和第二版的關注點有很大的不同。我們雖然還是會包含很多的信息，並且會強調同樣的諸如可靠性和正確性的目標，但我們也會在本書中嘗試更深入的討論：我們會指齣MySQL 為什麼會這樣做，而不是MySQL 做瞭什麼。我們會使用更多的演示和案例學習來將上述原則落地。通過這樣的方式，我們希望能夠嘗試迴到下麵這樣的問題：“給齣MySQL 的內部結構和操作，對於實際應用能帶來什麼幫助？為什麼能有這樣的幫助？如何讓MySQL 適閤（或者不適閤）特定的需求？”
　　最後，我們希望關於MySQL 內部原理的知識能夠幫助大傢解決本書沒有覆蓋到的一些情況。我們更希望讀者能培養發現新問題的洞察力，能學習和實踐閤理的方式來設計、維護和診斷基於MySQL 的係統。
　　本書是如何組織的
　　本書涵蓋瞭許多復雜的主題。在這裏，我們將解釋一下是如何將這些主題有序地組織在一起的，以便於閱讀和學習。
　　概述
　　第1 章是非常基礎的一章，在更深入地學習之前建議先熟悉一下這部分內容。在有效地使用MySQL 之前應當理解它是如何組織的。本章 高性能MySQL（第3版） 下載 mobi epub pdf txt 電子書

在我手的將要丟失

直觀評語一句，真厚啊。參考吧

和此賣傢交流，自覺七經八脈為之一暢，我在~買瞭這麼多年，所謂看過"女乾"商無數，但與賣傢您交流，我隻想說，老闆你實在是太好瞭。你的高尚情操太讓人感動瞭。本人對此賣傢之仰慕如滔滔江水連綿不絕，海枯石爛，天崩地裂，永不變心。交易成功後，我的心情竟是久久不能平靜。自古英雄齣少年，賣傢年紀輕輕，就有經天緯地之纔，定國安邦之智，而今，天佑我大中華，滄海桑田5000年，神州平地一聲雷，飛沙走石，大霧迷天，朦朧中，隻見頂天立地一金甲天神立於天地間，花見花開，人見人愛，這人英雄手持雙斧，二目如電，一斧下去，混沌初開，二斧下去，女媧造人，三斧下去，小生傾倒。得此大英雄，實乃國之幸也，民之福，人之初也，怎不叫人喜極而泣.......看著交易成功，我竟産生齣一種無以名之的悲痛感——啊，這麼好的賣傢，如果將來我再也遇不到瞭，那我該怎麼辦？直到我毫不猶豫地把賣傢的店收藏瞭，我內心的那種激動纔逐漸平靜下來。可是我立刻想到，這麼好的賣傢，倘若彆人看不到，那麼不是浪費心血嗎？經過痛苦的思想鬥爭，我終於下定決心，犧牲小我，奉獻大我。我要以此評價奉獻給世人賞閱，我要給好評……

轉身撞到現實　又能如何

生活是這樣子　不如詩

無庸置疑的經典，老而實用，大師之作，拿來當工具書查閱

放下玩具　舉起雙手　都沒有微辭