“隻要你不敢以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 的架構及其存儲引擎的關鍵設計。如果讀者還不太熟悉關係數據庫和事務的基礎知識,本章也可以帶來一點幫助。如果之前已經對其他關係數據庫如Oracle 比較熟悉,本章也可以幫助讀者瞭解MySQL 的入門知識。本章還包括瞭一點MySQL 的曆史背景:MySQL 隨著時間的演進、最近的公司所有權更替,以及我們認為比較重要的內容。
打造堅實的基礎
本書前幾章的內容在今後使用MySQL 的過程中可能會被不斷地引用到,它們是非常基礎的內容。
第2章討論瞭基準測試的基礎,例如服務器可以處理的工作負載的類型、處理特定任務的速度等。基準測試是一項至關重要的技能,可用於評估服務器在不同負載下的錶現,但也要明白在什麼情況下基準測試不能發揮作用。
第3章介紹瞭我們常用於故障診斷和服務器性能問題分析的一種麵嚮響應時間的方法。該方法已經被證明可以解決我們曾碰到過的一些極為棘手的問題。當然也可以選擇修改我們所使用的方法(實際上我們的方法也是從Cary Millsap 的方法修改而來的),但無論如何,至少不能沒有方法鬍亂猜測。
從第4章到第6 章,連續介紹瞭三個關於良好的數據庫邏輯設計和物理設計基礎的話題。第4 章涵蓋瞭不同數據類型的細節差彆以及錶設計的原則。第5 章則展開討論瞭索引,這是數據庫的物理設計。對於索引的深入理解和利用是高效使用MySQL 的基礎,相信這一章會經常需要迴頭翻看。而第6 章則包含瞭分析MySQL 的查詢是如何執行的,以及如何利用查詢優化器的話題。該章也包含瞭大量常見類型查詢的例子,演示瞭MySQL 是如何做好工作的,以及如何改寫查詢以利用MySQL 的特性。
到此為止,已經覆蓋瞭關於數據庫的基礎內容:錶、索引、數據和查詢。第7 章則在MySQL 基礎知識之外介紹瞭MySQL 的高級特性是如何工作的。這章的內容包括分區、存儲引擎、觸發器,以及字符集。MySQL 中這些特性的實現可能不同於其他數據庫,可能之前讀者並不清楚這些不同,因此理解它們對於性能可能會帶來新的收益。
配置應用程序
接下來的兩章講述的是如何讓MySQL、應用程序及硬件一起很好地工作。第8 章介紹瞭如何配置MySQL,以便更好地利用硬件,達到更好的可靠性和魯棒性。第9 章解釋瞭如何讓操作係統和硬件工作得更好。另外也深入討論瞭固態硬盤,為高可擴展性應用發揮更好的性能提供瞭硬件配置的建議。
上麵兩章都一定程度地涉及瞭MySQL 的內部知識。這將會是一個反復齣現的主題,附錄中也會有相關內容可以學習到MySQL 的內部是如何實現的,理解瞭這些知識將幫助讀者更好地理解某些現象背後的原理。
作為基礎設施組件的MySQL
MySQL 不是存在於真空中的,而是應用整體的一個環節,因此需要考慮整個應用架構的魯棒性。下麵的章節將告訴我們該如何做到這一點。
第10 章討論瞭MySQL 的殺手級特性:能夠設置多個服務器從一颱主服務器同步數據。不幸的是,復製可能也是MySQL 給很多用戶帶來睏擾的一個特性。但實際上不應該發生這樣的情況,本章將告訴你如何讓復製運行得更好。
第11章討論瞭什麼是可擴展性(這和性能不是一迴事),應用和係統為什麼會無法擴展,該怎麼改善擴展性。如果能夠正確地處理,MySQL 的可擴展性是足以應付任何需求的。
第12章講述的是和可擴展性相關但又完全不同的主題:如何保障MySQL 穩定而正確地持續運行。第13 章將告訴你當MySQL 在雲計算環境中運行時會有什麼不同的事情發生。
第14章解釋瞭什麼是全方位的優化(full-stack optimization),就是從前端到後端的整體優化,從用戶體驗開始直到數據庫。
即使是世界上設計最好、最具可擴展性的架構,如果停電會導緻徹底崩潰,無法抵禦惡意攻擊,解決不瞭應用的bug 和程序員的錯誤,以及其他一些災難場景,那就不是什麼好的架構。第15 章討論瞭MySQL 數據庫各種備份與恢復的場景。這些策略可以幫助讀者減少在各種不可抗的硬件失效時的宕機時間,保證在各種災難下的數據最終可恢復。
其他有用的主題
在本書的最後一章以及附錄中,我們探討瞭一些無法明確地放到前麵章節的內容,以及一些被前麵多個章節引用而需要特彆注意的主題。
第16章探索瞭一些可以幫助用戶更有效地管理和監控MySQL 服務器的工具,有些是開源的,也有些是商業的。
附錄A 介紹瞭近年來成長迅速的三個主要的非MySQL 官方版本,其中一個是我們公司在維護的産品。知道還有其他什麼是可用的選擇是有價值的;很多MySQL 難以解決的棘手問題在其他的變種版本中說不定就不是問題瞭。這三個版本中的兩個(Percona Server 和MariaDB)是MySQL 的完全可替換版本,所以嘗試使用的成本相對來說是很低的。當然,在這裏我們也需要補充一點,Oracle 提供的MySQL 官方版本對於大多數用戶來說都能服務得很好。
附錄B 演示瞭如何檢查MySQL 服務器。知道如何從服務器獲取狀態信息是非常重要的;而瞭解這些狀態代錶的意義則更加重要。這裏將覆蓋SHOW INNODB STATUS 的輸齣結果,因此這裏包含瞭InnoDB 事務存儲引擎的深入信息。在這個附錄中討論瞭很多InnoDB的內部信息。
附錄C 演示瞭如何高效地將大文件從一個地方復製到另外一個地方。如果要管理大量的數據,這種操作是經常都會碰到的。附錄D 演示瞭如何真正地使用並理解EXPLAIN 命令。附錄E 演示瞭如何破除不同查詢所請求的鎖互相乾擾的問題。最後,附錄F 介紹瞭Sphinx,一個基於MySQL 的高性能的全文索引係統。
書還不錯,適閤對數據庫有一點基礎知識的人閱讀,裏麵有一些小錯誤,瑕不掩瑜吧
評分 評分放下玩具 舉起雙手 都沒有微辭
評分書的質量和內容還行,就是快遞送過來的拆開一看,書是被什麼硬東西磕過的,書邊都磕壞瞭
評分這是個很久遠的事
評分書是正版,就是感覺紙張太薄瞭。不過也確實有點厚
評分4號給我,我在看電視,你是恩我啊你在上班沒有時間啊!。?噢
評分 評分本站所有內容均為互聯網搜尋引擎提供的公開搜索信息,本站不存儲任何數據與內容,任何內容與數據均與本站無關,如有需要請聯繫相關搜索引擎包括但不限於百度,google,bing,sogou 等
© 2025 windowsfront.com All Rights Reserved. 靜流書站 版權所有