其他

通過對比用phpMyAdmin從MySQL和MySQL5匯出wordpress資料的不同點，從而解決遷移中的出錯問題，這個解決方案不是僅用在遷移Wordpress資料上，實際上是通用的。利用phpMyAdmin（MySQL＆phpMyAdmin安裝於Win下）在MySQL4中選擇資料庫“匯出”需要的wordpress資料，如圖選擇“另存新檔檔案”這樣就得到一個尾碼為.sql的匯出檔案儲存在本地機子上。用phpMyAdmin開啟MySQL5，如圖預設

InnoDB中，索引所扮演的角色是非常重要的。因為它們可以能讓語句鎖定更少的行。這是個要考慮的事情，因為在MySQL5.0

MySQL有兩種方法產生有序的結果：使用檔案排序或者按順序的掃描索引。你可以使用EXPLAIN來查看type列是否是index來得知MySQL是否計劃的掃描索引。掃描索引本身是非常快速的，因為它只是簡單的需要從一個索引實體移動到下一個。然而，如果MySQL沒有使用索引覆蓋這個查詢，它就會尋找在索引中發現的每一行。這是個隨機IO的過程，因此從索引順序中讀取資料比連續表的掃描要慢很多。MySQL可以使用相同的索引來排序和尋找行。如果可能，同時滿足這兩個任務是再好不過的事情了。當索引的順序和order

如果你在一個查詢中不隔離已經索引的列，一般來說MySQL就不會使用這個列上的索引，除非在查詢中隔離這個列。“隔離”列的意思就是，這個列不能使一個運算式的一部分或者被放在一個函數的內部。舉個例子，在這個查詢中，你不能使用在actor_id上的索引。mysql> SELECT actor_id FROM sakila.actor WHERE actor_id + 1 =

建立正確的索引和正確的使用它們，是獲得好的查詢效能的關鍵所在。我們已經介紹了不同種類的索引並且探究了它們的優缺點。現在讓我們來看看怎樣深入的使用強大的索引。有許多高效的選擇和使用索引的方法，因為有很多特殊情況的最佳化以及一些專門的行為。決定什麼時候使用並且評估你的選擇對效能所造成的潛在影響，這些也是我們將會學的技能。接下來的部門會教你怎樣高效的使用索引，但是千萬不要忘了進行基準測試。

特殊類型的資料一些特殊類型的資料可能並不直接的和MySQL內建類型相吻合。一個例子就是用STAMPTIME儲存更精確的時間。另一個例子是IP地址。人們常常使用VARCHAR(15)來儲存IP地址。然而，一個IP地址其實是一個無符號的32bit的整型，並不是一個字串。IP地址的點兒僅僅是為了方便人們去讀取IP地址而已。你應該用無符號整型去儲存IP地址。MySQL提供了INET_ATON()和INET_NTOA()函數來解決這兩種類型的轉換。以後的MySQL版本。它會提供一個專門來儲存IP的地址的資

MySQL有很多使用單獨的bit去儲存資料的類型。不管底層的儲存格式以及操作，從技術上來看所有的這些類型都是字串類型。BIT在5.0之前的版本，BIT僅僅等同於TINYINT。但是在5.0之後的版本，它已經是個具有一些特性的，和以前完全不同的資料類型了。我們在這討論的是新增加的特性。你可以使用BIT列儲存一個或多個true/false值。BIT(1)定義了一個包含1個bit的欄位，BIT(2)儲存了2個bits.如此類推。。BIT最大長度是64bits.不同儲存引擎,BIT的特性是不同的。MyI

字串類型MySQL支援很多字串類型，以及它們的許多變化類型。這些資料類型在4.1和5.0版本變化都比較大。可以說變得更複雜了。早在4.1版本中，每個字串列都有自己的字元集和對於那些字元集的定序，或者叫做collation（校對）。VARCHAR和CHAR有兩個主要的字串類型就是VARCHAR和CHAR。它們都儲存了字元值。不幸的是，很難準確解釋這些值怎樣儲存在硬碟和記憶體中，因為這些都是有儲存引擎實現的。我們假設你使用的是MyISAM和/或者InnoDB.如果不是，你最好查閱你使用儲存引擎的相關

整數總共有兩種數字類型：整數和實數（有小數部分的）。如果你儲存的是整數，使用下列的整型：TINYINT,SMALLINT,MEDIUMINT,INT或者BIGINT。它們分別需要8,16,24,32,以及64位的儲存空間。它們儲存的值範圍為N就是它們使用的儲存空間所需的位元。整型有個一個可選擇的參數，就是UNSIGNED，它不允許儲存負數，而正數的最大上限變為之前的大約兩倍左右。舉個例子，一個TINYINT

日期和時間類型MySQL對於不同種類的日期和時間有很多的資料類型，比如YEAR和DATE。MySQL可儲存時間顆粒度是一秒。然而，時間的計算可以精確到毫秒。我們將會教你如何解決儲存引擎的局限性。大部分時間類型都沒有什麼可選擇的。所以那個是最佳的選擇不是一個問題。只有一個問題那就是當你即要儲存日期也要儲存時間的時候，將要做什麼。MySQL提供了兩個類型來滿足這個需求:DATETIME和TIMESTAMP.對許多應用而言，任意一個都可以，但是在一些案例中，一個要好於另一個。讓我們來看看：DATETI

對於主鍵，選擇一個好的資料類型尤為關鍵。你可能經常需要用這些列和其他做比較以及用這些列尋找其他的列。你可能也把它們作為另一些表的外鍵。因此當你選擇主鍵的資料類型時，應該保持相關表主鍵類型一致。當選擇主鍵的資料類型，你不僅要考慮儲存類型，也要考慮MySQL操作和比較這些類型的表現情況。比如，MySQL內部儲存ENUM和SET是作為整型的，但是當在字串環境下作比較的時候，MySQL會把它們轉為字串。一旦你選擇了一個類型，要確定相關表都要使用這個類型。這個類型一定要精確，包括了它的屬性，如UNSIGN

越小也就是越好的一般來說，盡量選擇小的資料類型足以符合你的儲存和展現資料。越小的資料類型也常常是越快的，因為它們使用了較少的硬碟空間，記憶體，CPU緩衝。它們也需要更少的CPU處理周期。要確定的是不要低估你要儲存數值的範圍，因為在你的Schema的多個位置中，增長的資料類型範圍會讓操作很費力費時。如果你對不知道選擇什麼樣的資料類型，那麼就選擇一個最小的，當然要確保資料不會越界。簡單的就是好的對於單一資料型別的操作，不需要太多的CPU周期。比如，整型之間的比較要比字元之間的比較消耗更低。因為字元集

用例子來理解索引的概念是再簡單不過的方法了。因此我們研究一個索引樣本。假使我們要做一個線上約會的網站。使用者的資料就會有很多列，比如country, state/region, city, sex, age, eye

有很多方法來展現給定的資料。從完全範式到完全的非範式以及介於兩者之間。在符合範式的資料庫中，每個事實展現一次並且僅僅展現一次而已。相反的，在非範式的資料庫，資訊重複或者儲存在很多的地方。如果你不熟悉範式，你應該加強學習了。關於範式，你可以通過一些書和網上資源來學習。在這裡，我們主要介紹這一章中你應該明白的知識。讓我們看看經典的例子，那就是employee,departments,和department heads.EMPLOYEE 　 　 　 　 　 　 DEPARTMENT 　 　 　 　 　

這一章的結束，我們來說一下關於設計模型的儲存引擎的選擇，這些你應該牢記。我們不會全面的介紹儲存引擎，目標就是列出一些影響資料模型設計的一些關鍵性因素。MyISAM儲存引擎表鎖（Table locks）MyISAM是表一級的鎖。小心地是這個不會成為一個瓶頸。沒有自動資料恢複（No automated data recovery）如果MySQL伺服器掛了或者電源關閉。你應該在使用表之前來修複MyISAM表。如果有個大表，這個過程可能會持續幾個小時。不支援事物（No

當對於一個大表進行ALTER TABLE的時候，效能問題就產生了。MySQL大部分改動的步驟如下：根據新的表結構建立一個空表，從舊錶中把資料取出來插入到新表中，在刪除舊錶。這是個非常漫長的過程。許多人ALTER TABLE之後，都有等待1小時或者1天的痛苦經曆。MySQL

當你已經建立了一張表，有合適的資料類型，並添加了索引之後，其實你的工作還並沒有結束：你還需要維護你的表和索引使它們工作的更好。表的維護有三個主要的目標：發現和解決表的損壞，維護準確的索引統計，並且要降低儲存片段。找到和修複損壞的表最差的事情莫過於表已經損壞了。對於MyISAM，大部分是由於當機所造成的。然而，所有的儲存引擎都會由於硬體問題或者MySQL內部BUG再或者作業系統的原因導致索引的損壞。損壞的索引能導致查詢返回不正確的結果，當沒有重複值出現卻拋出重複索引值的錯誤，或者導致查詢死結和當機

全文索引FULLTEXT是MyISAM表的一個特殊的索引類型。它在文本中找到一個關鍵詞，而並不是在索引中直接比較著兩個值。Full-text搜尋不同於其他類型的匹配。它有許多細微的差別。比如stopwords，stemming,plurals以及Boolean searching。這些基本都和搜尋引擎相關了。給一個列加全文索引並不能消除B-Tree索引的值。全文索引是匹配而不是WHERE條件的操作。我們會在全文檢索搜尋中，詳細討論。

Hash索引Hash索引是建立在Hash table至上的，並且它只對準確尋找有效，也就是說，必須尋找索引上的每一個列。對於每個行，儲存引擎計算了索引列的Hash code。這個hash code是非常小，並且對於其他行不同的數值，這些Hash code也是不相同的。在索引中儲存了hash code並且在hash

索引的類型索引有許多類型，它們都是針對不同的用途而被設計的。索引是在儲存引擎中實現的，而不是伺服器。因此它們並沒有標準化：在每個引擎中，索引工作的方式都有所不同，並且並不是所有的儲存引擎支援所有種類的索引。即使這些儲存引擎支援索引的類型相同，在底層的實現也是有所不同。讓我們來看看MySQL所支援的索引類型，它們的優勢和缺點。B-Tree索引當人們討論索引而沒有說明它的類型的時候，往往指的是B-Tree索引。它用B-Tree資料結構儲存了資料。大部分MySQL儲存引擎都支援這種類型。Archive