MYSQL性能調優

摘要

爲了學習研究MySQL數據庫在工做原理，深入理解MySQL在企業運用時如何保證其高效運行。分別從表結構的優化，SQL語句的優化，存儲引擎的選擇，索引的優化以及現今MySQL的發展與其餘企業級數據庫的比較。介紹了從編碼選擇到數據類型的選擇以及從總體的角度設計表結構。在SQL語句的選擇和使用的介紹的時候，深刻介紹了一些基本的使用原則以及在通常在使用過程當中咱們存在的誤區以及如何解決這些問題。着重介紹了MySQL的幾個存儲引擎MyISAM、InnoDB和NDBCluster的差別以及各自的適用範圍。有介紹了MySQL的索引的一些優化的建議以及高屋建瓴地闡述和比較了MySQL的優劣和發展態勢。

 

 

前言

 

 

數據庫做爲應用做爲普遍，地位極爲重要的中間件應用，學習和使用數據庫管理系統變得愈來愈重要。爲了研究和總結對mysql數據庫的學習結果，特別從數據表結構、sql語句優化、存儲引擎的選擇、索引的應用、以及mysql的比較總結對mysql技術作了一個比較全面升入的介紹。使用mysql的過程當中，如何更好地使用與優化愈來愈重要，在這篇文章中就闡述。

第一章 表結構的優化

數據表是數據庫的具體表現形式，設計優良的數據庫擁有良好的表結構，者不僅僅指數據庫的表須要知足範式結構，爲了更有利於具體操做，表結構還須要實際的可擴展性，以便於作增刪改查，又須要根據數據表的具體做用作出調節。在系統中被大量查詢的表的結構的設計會對系統性能產生極大的影響。若是說系統的和核心是數據庫的話，那麼設計數據庫的核心就是表結構的設計。

1.1 編碼的選擇

字符集直接決定了數據在MySQL中的存儲編碼方式，因爲一樣的內容使用不一樣字符集表示所佔用的空間大小會有較大的差別，因此經過使用合適的字符集，能夠幫助咱們儘量減小數據量，進而減小IO操做次數。不要使用UTF-8或其餘UNICODE字符類型，這樣能夠節約大若是沒有須要使用多語言，那麼最好量的存儲空間。

好比中文就能夠選擇GBK或者GB2313，而GBK是對GB2313的擴展，選擇的時候可視狀況而定。

1.2 表的拆分

有些時候，咱們可能會但願將一個完整的對象對應於一張數據庫表，這對於應用程序開發來講是頗有好的，可是有些時候可能會在性能上帶來較大的問題。當咱們的表中存在相似於TEXT或者是很大的VARCHAR類型的大字段的時候，若是咱們大部分訪問這張表的時候都不須要這個字段，咱們就該義無反顧的將其拆分到另外的獨立表中，以減小經常使用數據所佔用的存儲空間。這樣作的一個明顯好處就是每一個數據塊中能夠存儲的數據條數能夠大大增長，既減小物理IO次數，也能大大提升內存中的緩存命中率。

1.3 數據類型的選擇

數據庫操做中最爲耗時的操做就是IO處理。據統計，數據庫操做90%以上的時間都花在了IO上面。因此儘量減小IO量，能夠在很大程度上提升數據庫操做的性能。

MySQL的數據類型能夠精確到字段，因此當咱們須要大型數據庫中存放多字節數據的時候，能夠經過對不一樣表不一樣字段使用不一樣的數據類型來較大程度減少數據存儲量，進而下降IO操做次數並提升緩存命中率。數據類型選擇的核心思想很簡單，就是吝嗇地選擇所佔空間最小的數據類型。

下面的這些關於字段類型的優化建議主要適用於記錄條數較多，數據量較大的場景，由於精細化的數據類型設置可能帶來維護成本的提升，過分優化也可能會帶來其餘的問題：

1.3.1 數字類型

儘可能不要使用DOUBLE，不只僅只是存儲長度的問題，同時還會存在精確性的問題。一樣，固定精度的小數，也不建議使用DECIMAL，能夠乘以固定倍數轉換成整數存儲，能夠大大節省存儲空間，且不會帶來任何附加維護成本。對於整數的存儲，在數據量較大的狀況下，須要分開 TINYINT、INT和BIGINT的選擇，由於三者所佔用的存儲空間也有很大的差異，能肯定不會使用負數的字段，最好添加unsigned定義。

1.3.2 字符類型

儘可能減小使用TEXT數據類型，由於它的性能要低於char或者是varchar類型的處理。定長字段，使用CHAR 類型，不定長字段使用VARCHAR，且僅僅設定適當的最大長度，而不是很是隨意的給一個很大的最大長度限定，由於不一樣的長度範圍，MySQL也會有不同的存儲處理。

1.3.3 時間類型

儘可能使用TIMESTAMP類型，其存儲空間只須要 DATETIME類型的一半。對於只須要精確到某一天的數據類型，建議使用DATE類型，由於他的存儲空間只須要3個字節，比TIMESTAMP還少。

1.3.4 ENUM & SET

對於狀態字段，使用 ENUM 來存放，由於能夠極大的下降存儲空間，並且即便須要增長新的類型，只要增長於末尾，修改結構也不須要重建表數據。若是是存放可預先定義的屬

性數據可使用SET類型，即便存在多種屬性，一樣能夠遊刃有餘，同時還能夠節省不小的存儲空間。

1.3.5 LOB類型

儘可能不要數據庫中存放 LOB 類型數據，對於這類大的數據類型，仍是使用文件形式存儲。

1.4 適度冗餘

以join操做爲例，mysql每次join都會有必定的性能的要求，若是該操做須要大量的進行而所取到又是獨立的小字段，在這種狀況下將該字段合併在一張表內可以大大地下降IO，提升效率。不過，冗餘的同時須要確保數據的一致性不會遭到破壞，確保更新的同時冗餘字段也被更新。

另外就是NULL了，若是是一個組合索引，那麼這個NULL類型的字段會極大影響整個索引的效率。此外NULL在索引中的處理也是特殊的，也會佔用額外的存放空間。不少人以爲 NULL 會節省一些空間，因此儘可能讓NULL來達到節省IO的目的，可是大部分時候這會拔苗助長，雖然空間上可能確實有必定節省，卻是帶來了不少其餘的優化問題，不但沒有將IO量省下來，反而加大了SQL的IO量。因此儘可能確保默認值值不是 NULL，也是一個很好的表結構設計優化習慣。

 

 

 

 

第二章 SQL語句的優化

在進行SQL優化的時候，咱們必須明確目的，也就是減小IO次數。

IO永遠是數據庫最容易瓶頸的地方，這是由數據庫的職責所決定的，大部分數據庫操做中超過90%的時間都是IO操做所佔用的，減小IO次數是SQL優化中須要第一優先考慮。固然，也是收效最明顯的優化手段。另外就是下降CPU計算了，除了IO瓶頸以外，SQL優化中須要考慮的就是CPU運算量的優化了。order by, group by,distinct…都是最消耗CPU的，由於這些操做基本上都是CPU處理內存中的數據比較運算。當咱們的IO優化作到必定階段以後，下降CPU計算也就成爲了咱們SQL優化的重要目標。

2.1 SQL優化原則

通常狀況下，寫好SQL語句首先須要一個良好的思路，如何將幾張有用的表經過一個清晰的關係鏈接起來。每每思路越清晰獲得的SQL的性能也就越好，要是原本簡單的關係經過繞了一圈獲得了一個結果，可想而知計算機處理的時候也就要繞一大圈，天然下降了執行的性能。

2.1.1 儘可能少join

MySQL的優點在於簡單，但這在某些方面其實也是其劣勢。MySQL優化器效率高，可是因爲其統計信息的量有限，優化器工做過程出現誤差的可能性也就更多。對於複雜的多表Join，一方面因爲其優化器受限，再者在Join這方面所下的功夫還不夠，因此性能表現離Oracle等關係型數據庫前輩仍是有必定距離。但若是是簡單的單表查詢，這一差距就會極小甚至在有些場景下要優於這些數據庫前輩。

2.1.2 儘可能少排序

排序操做會消耗較多的CPU資源，因此減小排序能夠在緩存命中率高等IO能力足夠的場景下會較大影響SQL的響應時間。對於MySQL來講，減小排序有多種辦法，好比：經過利用索引來排序的方式進行優化,減小參與排序的記錄條數,非必要不對數據進行排序.

2.1.3 儘可能避免select *

一方面select *的性能很差，顯而易，它比select xx，yy from tt多花費的是得到表中各屬性的性能。例外，咱們在查詢一張表獲取一組數據的時候，大多數的時候並不須要這張表中的全部項，這時候簡單地使用select *就會形成得到冗餘的數據和浪費額外的IO。

2.1.4 儘可能用join代替子查詢

咱們剛纔講到儘可能少使用join，可是join在有的時候是必需要使用的，特別是幾張表一塊兒處理的時候。而相對於join，子查詢更加消耗性能。這個也很容易理解，由於子查詢的時候會在內存中內子查詢的結果生成一張表而後再通過父查詢得出最終結構，至關於經歷了屢次查詢並且浪費了必定的內存空間。

2.1.5 儘可能少 or

由於不少時候使用 union all 或者是union（必要的時候）的方式來代替「or」會獲得更好的效果。

2.1.6 儘可能用 union all 代替 union

union 和 union all 的差別主要是前者須要將兩個（或者多個）結果集合並後再進行惟一性過濾操做，這就會涉及到排序，增長大量的CPU運算，加大資源消耗及延遲。因此當咱們能夠確認不可能出現重複結果集或者不在意重複結果集的時候，儘可能使用 union all 而不是 union。

2.1.7 儘可能早過濾

這一優化策略其實最多見於索引的優化設計中，將過濾性更好的字段放得更靠前。在SQL編寫中一樣可使用這一原則來優化一些Join的SQL。好比咱們在多個表進行分頁數據查詢的時候，咱們最好是可以在一個表上先過濾好數據分好頁，而後再用分好頁的結果集與另外的表 Join，這樣能夠儘量多的減小沒必要要的 IO 操做，大大節省 IO 操做所消耗的時間。

2.1.8 避免類型轉換

這裏所說的「類型轉換」是指 where 子句中出現 column 字段的類型和傳入的參數類型不一致的時候發生的類型轉換：

人爲在column_name 上經過轉換函數進行轉換，直接致使 MySQL（實際上其餘數據庫也會有一樣的問題）沒法使用索引，若是非要轉換，應該在傳入的參數上進行轉換，由數據庫本身進行轉換若是咱們傳入的數據類型和字段類型不一致，同時咱們又沒有作任何類型轉換處理，MySQL可能會本身對咱們的數據進行類型轉換操做，也可能不進行處理而交由存儲引擎去處理，這樣一來，就會出現索引沒法使用的狀況而形成執行計劃問題。

2.1.9 優先優化高併發的 SQL

對於破壞性來講，高併發的 SQL 老是會比低頻率的來得大，由於高併發的 SQL 一旦出現問題，甚至不會給咱們任何喘息的機會就會將系統壓跨。而對於一些雖然須要消耗大量IO並且響應很慢的SQL，因爲頻率低，即便遇到，最多就是讓整個系統響應慢一點，但至少可能撐一下子，讓咱們有緩衝的機會。

2.1.10 從全局出發優化，而不是片面調整

SQL 優化不能是單獨針對某一個進行，而應充分考慮系統中全部的SQL，尤爲是在經過調整索引優化SQL的執行計劃的時候，千萬不能顧此失彼，因小失大。儘量對每一條運行在數據庫中的SQL進行explain。優化 SQL，須要作到心中有數，知道 SQL的執行計劃才能判斷是否有優化餘地，才能判斷是否存在執行計劃問題。在對數據庫中運行的 SQL 進行了一段時間的優化以後，很明顯的問題 SQL 可能已經不多了，大多都須要去發掘，這時候就須要進行大量的 explain 操做收集執行計劃，並判斷是否須要進行優化。

2.2 SQL優化誤區

在咱們生活中有不少咱們想固然的事情，可是事實卻正好相反。在SQL優化的過程當中也有這樣的誤區。

2.2.1 關於count() 的一些誤區

一般咱們會認爲count(1)和count(primary_key)要優於 count(*)。

不少人爲了統計記錄條數，就使用 count(1) 和 count(primary_key) 而不是 count(*) ，他們認爲這樣性能更好，其實這是一個誤區。對於有些場景，這樣作可能性能會更差，由於數據庫對 count(*) 計數操做作了一些特別的優化。

可是count(column) 和 count(*) 是同樣的嗎？

這個誤區甚至在不少的資深工程師或者是 DBA 中都廣泛存在，不少人都會認爲這是理所固然的。實際上，count(column)和 count(*) 是一個徹底不同的操做，所表明的意義也徹底不同。

count(column) 是表示結果集中有多少個column字段不爲空的記錄。

count(*) 是表示整個結果集有多少條記錄。

2.2.2 關於select 的一些誤區

一樣通常咱們會認爲select a,b from … 比 select a,b,c from … 可讓數據庫訪問更少的數據量，於是效率會更高。

這個誤區主要存在於大量的開發人員中，主要緣由是對數據庫的存儲原理不是太瞭解。

實際上，大多數關係型數據庫都是按照行（row）的方式存儲，而數據存取操做都是以一個固定大小的IO單元（被稱做 block 或者 page）爲單位，通常爲4KB，8KB… 大多數時候，每一個IO單元中存儲了多行，每行都是存儲了該行的全部字段（lob等特殊類型字段除外）。

因此，咱們是取一個字段仍是多個字段，實際上數據庫在表中須要訪問的數據量實際上是同樣的。

固然，也有例外狀況，那就是咱們的這個查詢在索引中就能夠完成，也就是說當只取 a,b兩個字段的時候，不須要回表，而c這個字段不在使用的索引中，須要回表取得其數據。在這樣的狀況下，兩者的IO量會有較大差別。

2.2.1 使用order by必定須要排序操做？

咱們知道索引數據其實是有序的，若是咱們須要的數據和某個索引的順序一致，並且咱們的查詢又經過這個索引來執行，那麼數據庫通常會省略排序操做，而直接將數據返回，由於數據庫知道數據已經知足咱們的排序需求了。

實際上，利用索引來優化有排序需求的 SQL，是一個很是重要的優化手段。

第三章 存儲引擎的優化

MySQL的存儲引擎是關係型數據庫產品中最具備特點的了，不只能夠同時使用多種存儲引擎，並且每種存儲引擎和MySQL之間使用插件方式這種很是鬆的耦合關係。在應對不一樣場景的處理的時候，選擇不一樣的存儲引擎可以有效地提升存儲效率。

3.1 MyISAM

3.1.1 MyISAM的特性

MyISAM存儲引擎不支持事務，因此對事務有要求的業務場景不能使用。其鎖定機制是表級索引，這雖然可讓鎖定的實現成本很小可是也同時大大下降了其併發性能。

不只會在寫入的時候阻塞讀取，MyISAM還會在讀取的時候阻塞寫入，但讀自己並不會阻塞另外的讀。MyISAM能夠經過key_buffer緩存以大大提升訪問性能減小磁盤IO，可是這個緩存區只會緩存索引，而不會緩存數據。

3.1.2 MyISAM的適用性

MyISAM適用於不須要事務支持、併發性相對較低、數據修改相對較少的場景下。通常這類的系統會以讀爲主，對數據一致性要求不是很高。

在使用該引擎的時候，能夠儘可能利用其緩存機制使用索引。而且調整讀寫的優先級，根據實際需求確保重要操做更優先。在必要的時候啓用延遲插入改善大批量寫入性能。在進行插入操做的時候儘可能順序操做讓insert數據都寫入到尾部，減小阻塞。同時，分解大的操做，下降單個操做的阻塞時間。並注意下降併發數，某些高併發場景經過應用來進行排隊機制。處理相對靜態的數據時，充分利用Query Cache能夠極大的提升訪問效率。另外，MyISAM的Count只有在全表掃描的時候特別高效，帶有其餘條件的count都須要進行實際的數據訪問。

3.2 InnoDB

3.2.1 InnoDB的特性

相對於MyISAM，InnoDB徹底支持4個事務隔離級別，並支持多版本讀。經過索引實現了行級鎖定，但全表掃描仍然會是表鎖，使用的時候注意間隙鎖的影響。而且讀寫阻塞與事務隔離級別相關。具備很是高效的緩存特性：能緩存索引，也能緩存數據。整個表和主鍵以Cluster方式存儲，組成一顆平衡樹。全部Secondary Index都會保存主鍵信息。

3.2.2 InnoDB的適用性

InnoDB具備較好的事務特性，也就是須要事務支持。其行級鎖定機制對高併發有很好的適應能力，但須要確保查詢是經過索引完成。可以很好地適用於數據更新較爲頻繁的場景，可是對數據一致性要求較高。若是硬件設備內存較大，能夠利用InnoDB較好的緩存能力來提升內存利用率，儘量減小磁盤 IO。

使用InnoDB須要注意主鍵儘量小，避免給Secondary index帶來過大的空間負擔；避免全表掃描，由於會使用表鎖；儘量緩存全部的索引和數據，提升響應速度；在大批量小插入的時候，儘可能本身控制事務而不要使用autocommit自動提交；合理設置innodb_flush_log_at_trx_commit參數值，不要過分追求安全性；避免主鍵更新，由於這會帶來大量的數據移動。

3.3 NDBCluster

3.3.1 NDBCluster的特性

NDBCluster對mysql的重要的貢獻就是將分佈式的概念引人了進來。做爲分佈式存儲引擎，能夠由多個NDBCluster存儲引擎組成集羣分別存放總體數據的一部分。NDBCluster和Innodb同樣，也支持事務。可與mysqld不在一臺主機，也就是能夠和mysqld分開存在於獨立的主機上，而後經過網絡和mysqld通訊交互。可是內存需求量巨大，索引以及被索引的數據必須存放在內存中。

3.3.2 NDBCluster的適用性

NDBCluster具備很是高的併發需求，對單個請求的響應並非很是的及時。查詢簡單，過濾條件較爲固定，每次請求數據量較少，又不但願本身進行水平分片。

在使用的時候儘量讓查詢簡單，避免數據的跨節點傳輸；儘量知足SQL節點的計算性能，大一點的集羣SQL節點會明顯多餘Data節點。在各節點之間儘量使用萬兆網絡環境互聯，以減小數據在網絡層傳輸過程當中的延時。

 

第四章 MySQL索引的優化

索引是數據庫中經常使用來提升性能的的技術，如何用好索引成爲數據庫實現性能最大化的很重要的一方面。

4.1 索引的概述

如何進行高質量的SQL編程，對索引的理解使用是關鍵的。正確地使用索引能夠是SQL語句運行得更快，而錯誤的添加索引可能會帶來災難性的結果。

4.2 索引設計的原則

索引的設計能夠遵循一些已有的原則，建立索引的時候先儘可能考慮符合這些規則，便於提高索引的使用效率，更好更高效地使用索引。

搜索的索引列，不必定是所要選擇的列。換句話說，適合索引的列是出如今WHERE子語句中的列，或鏈接句中指定的列，而不是出如今SELECT關鍵字後的選擇列表中的列。

使用惟一的索引。考慮到類中值的分佈。索引的列的基數越大，索引的效果越好。例如，存放出生日期的列具備不一樣的值，很容易區分各行。而用來記錄性別的列，只含有「M」和「F」，則對此列進行索引沒有多大的用處，由於無論搜索到哪一個值，都會得出一個大約一半的行。使用短索引。

若是對字符串列進行索引，應該指定一個前綴的長度，只要有可能就應該這樣作。例若有一個CHAR(100)的列，若是前10或20 個CHAR內，多項值是惟一的，那麼就不要對整個列進行索引了。對前10貨20個CHAR的索引能夠節約大量的縮影空間，也可能使查詢更快。並且較小的索引進行的IO更少，更短的值比起來消耗的CPU運算更少。更爲重要的是對於更短的鍵值，索引高速緩存中的塊可以容納更多地鍵值，所以內存中也就能放更對的值。這樣就增長了找到行而不是讀取索引中較多塊的可能。

利用最左前綴。在建立了n列索引是也就是建立了n個索引。多列索引能夠起到幾個索引的做用。由於能夠利用索引中最左的列集來匹配，也就是最左前綴。

不要過分使用索引。任何事物物極必反都是其固定的哲學定律。對於索引也是同樣。每一個索引都會佔有必定得磁盤空間下降讀寫操做的性能。在修改表的過程當中索引必須重建或更新。也就是索引越多所須要花費的時間久更長。所以在建立索引的時候須要控制好索引的對象，不能盲目的添加隨意。

第五章 MySQL的發展與比較

5.1 MySQL與Oracle的比較

實際上在Oracle收購了sun以後MySQL一併變成了Oracle的一款產品，對於Oracle與MySQL的比較也就是至關與Oracle公司內部不一樣部門的比較，以及不一樣部門選擇的技術與策略的比較。其實MySQL的發展也愈來愈像是一個簡版的Oracle。

一、組函數的用法規則：

MySql中組函數在select語句中能夠隨意使用，但Oracle中若是查詢語句中有組函數，那其餘列名必須是組函數處理過的，或者groupby 子句中的列，負則會報錯。

二、自動增加的數據類型處理：

MySql有自動增加數據類(auto_increment)，插入記錄是不用操做此字段，會自動得到數據值，Oracle中沒有自動增加數據類型，須要使用Sequence序列號。

三、單引號的處理：

MySql裏能夠用雙引號包其字符串，Oracle只能夠用單引號。

四、翻頁的sql語句處理：

MySql翻頁的語句比較簡單，用Limit開始位置，記錄個數，Oracle處理翻頁的sql語句比較繁瑣，須要藉助於NUMROW。

五、日期處理：

MySql日期字段分Date和time兩種，Oracle日期字段只有Date，包含年月日時分秒MySql存儲當前時間用now(),Oracle用sysdate，或者將字符串轉換成日期的函數TO_DATE(‘2001-08-01’,’YYYY-MM-DD’)。

六、空字符的處理

MYSQL的非空字段也有空的內容，ORACLE裏定義了非空字段就不允許有空的內容。按MYSQL的NOT NULL來定義ORACLE表結構，導數據的時候會產生錯誤。所以導數據時要對空字符進行判斷，若是爲NULL或空字符，須要把它改爲一個空格的字符串。

8.字符串的模糊比較

MYSQL裏用字段名like%‘字符串%’，ORACLE裏也能夠用字段名like%‘字符串%’但這種方法不能使用索引，速度不快，用字符串比較函數instr(字段名，‘字符串’)>0會獲得更精確的查找結果。

5.2 MySQL與SQL Server的比較

能夠說二者最重要的區別是MySql是一個開發開源的系統，而SQLServer則是一個保守閉源的數據庫系統。SQLServer服務器的狹隘的，保守的存儲引擎與MySQL服務器的可擴展，開放的存儲引擎絕然不一樣。雖然SQLServer也有sybase引擎，但MySQL可以提供更多種的選擇，如myisam, heap,innodb,and berkeley db。但MySQL不徹底支持陌生的關鍵詞，因此它比SQLServer服務器要少一些相關的數據庫。同時，MySQL也缺少一些存儲程序的功能，好比myisam引擎聯支持交換功能。
純粹就性能而言，MySQL是至關出色的，由於它包含一個缺省桌面格式myisam。myisam數據庫與磁盤很是地兼容而不佔用過多的cpu和內存。MySQL能夠運行於windows系統而不會發生衝突，在unix或相似unix系統上運行則更好。你還能夠經過使用64位處理器來獲取額外的一些性能。由於MySQL在內部裏不少時候都使用64位的整數處理。這事不少知名網站都使用MySQL做爲後臺數據庫。
當說起軟件的性能，SQLServer服務器的穩定性要比它的競爭對手強不少。可是，這些特性也要付出代價的。好比，必須增長額外複雜操做，磁盤存儲，內存損耗等等。
MySQL有一個用於改變數據的二進制日誌。由於它是二進制，這一日誌可以快速地從主機上覆制數據到客戶機上。即便服務器崩潰，這一二進制日誌也會保持完整，並且複製的部分也不會受到損壞。在SQLServer服務器中，你也能夠記錄SQLServer的有關查詢，但這須要付出很高的代價。
這兩個產品都有本身完整的安全機制。只要你遵循這些安全機制，通常程序都不會出現什麼問題。
恢復性也是MySQL的一個特色，這主要表如今myisam配置中。這種方式有它固有的缺欠，若是你不慎損壞數據庫，結果可能會致使全部的數據丟失。然而，對於SQLServer服務器而言就表現得很穩鍵。SQLServer服務器可以時刻監測數據交換點並可以把數據庫損壞的過程保存下來。
對於這兩種數據庫，若是非要讓我說出到底哪種更加出色，也許我會讓你失望。以個人觀點，任一對你的工做有幫助的數據庫都是很好的數據庫，沒有哪個數據庫是絕對的出色，也沒有哪個數據庫是絕對的差勁。我想要告訴你的是你應該多從你本身的須要出發，即你要完成什麼樣的任務？而不要單純地從軟件的功能出發。
若是你想創建一個.net服務器體系，這一體系能夠從多個不一樣平臺訪問數據，參與數據庫的管理，那麼你能夠選用SQLServer服務器。若是你想創建一個第三方站點，這一站點能夠從一些客戶端讀取數據，那麼MySQL將是最好的選擇。

5.3 MySQL的發展

學習一門技術，始終會去想這門技術從此的發展前景是怎麼樣的，將來時候還可以有活力的存在。做爲一個成熟的數據庫管理系統，要知足各類各樣的商業需求，功能確定是會被列入重點參考對象的。MySQL的早期版本功能很是簡單，只能作一些很基礎的結構化數據存取操做，可是通過多年的改進和完善以後，如今它已經基本具有了全部通用數據庫管理系統須要的相關功能。

雖然在功能方面MySQL數據庫做爲一個通用的數據庫管理系統暫時還沒法和PostgreSQL相比，可是其功能徹底能夠知足咱們的通用商業需求，提供足夠強大的服務。並且無論是哪種數據庫在功能方面都不敢聲稱本身比其餘任何一款商用數據庫管理系統都強，甚至都不敢聲稱可以擁有某類數據庫產品的全部功能。由於每一款數據庫管理系統都有自身的優點，也有自身的侷限，這都說明每一款產品重點服務的方向不同。

性能高一直是MySQL引以自豪的一個特色。在權威的第三方評測機構屢次測試比較各類數據庫TPCC值的過程當中，MySQL一直都有很是優異的表現，並且在其餘全部商用的通用數據庫管理系統中，僅僅有Oracle數據庫可以與其一較高下。

MySQL一直以來奉行一個原則，那就是在保證足夠穩定性的前提下，儘量地提升自身的處理能力。也就是說，在性能和功能方面，MySQL第一考慮的要素主要仍是性能，MySQL但願可以在知足客戶99%的需求的前提下，將剩餘的全部精力都用來努力提升系統性能，而不但願本身是一個比其餘任何數據庫的功能都要強大的產品。

整體來講，MySQL數據庫在發展過程當中一直追求三項原則：簡單、高效、可靠。從上面簡單的比較重也能夠看出，MySQL在這三項原則上面，沒有哪一項是作的很差的。並且，雖然功能並非MySQL自身追求的原則之一，可是考慮到當前用戶量急劇增加，用戶需求愈來愈多樣化，MySQL也不得不在功能方面作出大量的努力，以不斷知足客戶的新需求。

 

結論

隨着IT技術的發展，數據庫技術依然沒有改變其核心的功能，即便是各類NOSQL不斷涌現的今天，MySQL這類的關係型數據庫仍是擁有着重要的地位。學好MySQL這類的開源數據庫系統進一步可深刻探索行業發展的本質，退一步也能夠利用MySQL這個平臺提升本身的技術。本文所介紹的MySQL的一些基本知識可能只是冰山一角，在技術不斷髮展的今天對MySQL的研究還會不斷地深刻。特別是國內，在阿里巴巴發動的「去IOE」的大潮下，對開源系統的推進愈來愈大，做爲數據庫領域開源系統的頭牌，對MySQL的深度定製便成爲各大互聯網巨頭的一個研究方向。