前言

MySQL優化有兩大層面，第一是資料庫層面，第二是硬體層面。資料庫層面可以細分為以下幾個方面：

• 鎖策略優化
• 儲存引擎優化
• 伺服器配置優化
• 主從，讀寫分離
• 叢集，負載均衡

本文講解資料庫schema設計優化

高效的模型設計

適度冗餘（反正規化）

在很多人眼裡，資料庫schema滿足的正規化級別越高越好，目的是儘量減少資料的冗餘，保持資料一致。但是適當的冗餘能減少多表連線操作，這樣一來冗餘的欄位就需要手動維護（比如觸發器、訊息監聽欄位變更），以保持資料一致性。如果犧牲一點維護成本能換來更大的效能提升，那麼完全可以選擇冗餘

垂直拆分

將欄位從主表拆分出去放到另外的表中。適合垂直才拆分的欄位有：

1.內容很大，但訪問頻率低的欄位

存放內容較多，訪問頻率相對其他欄位少很多的欄位。由於內容較多，大部分情況佔整條記錄的80%以上，而資料庫中資料在資料檔案中的格式一般都是以一條一條記錄為單位來存放。也就是說，如果我們要查詢某些記錄的某幾個欄位，資料庫並不是只需要訪問我們需要查詢的哪幾個欄位，而是需要讀取其他所有欄位（可以在索引中完成整個查詢的情況除外），也無法做到只讀取我們需要的幾個欄位的資料。這樣，我們就不得不讀取包括大欄位在內的很多並不相干的資料。而由於大欄位所佔的空間比例非常大，自然所浪費的IO 資源也就非常之大了。拆分大欄位後需要join來查詢它，所以還需要滿足頻率低才行

2.頻繁更新，導致快取重新整理，但訪問頻率低的欄位

比如，你有一個叫“last_login”的欄位，它會在每次使用者登入時被更新。但是，每次更新時會導致該表的查詢快取被清空。所以，你可以把這個欄位放到另一個表中，這樣就不會影響你對使用者ID，使用者名稱，使用者角色的不停地讀取了，因為查詢快取會幫你增加很多效能。

水平拆分

當單表的資料量過大時，可以按照某種規則把資料劃分到不同的表或庫中，比如訂單表，可以按年份來劃分，不同年份的訂單資料可以存放到不同的地方；有比如使用者表可以按ID取模、按性別來劃分。

統計表準實時優化

對於更新是非常頻繁的，但並不要求實時準確的資料可能弄成準實時的，比如網站訪問量、使用者活躍數這類資訊，我們可以通過定時任務，每隔一段時間去統計一次。

選擇合適的資料型別

資料型別的選擇有下面幾個簡單原則：

1.更小的通常更好

一般情況下應該選擇正確儲存資料的最小資料型別，因為它暫用更少的磁碟、記憶體和CPU快取，並且處理的CPU週期更少

2.簡單就好

簡單資料型別的操作通常需要更少的CPU週期。例如，用整型代替字元型，因為字符集和校對規則（排序規則）使字元比較比整型更復雜；用內建型別而不是字串來儲存日期時間；整型儲存IP地址

3.儘量避免NULL

NULL使索引、索引統計和值的比較都更復雜

整數型別

可以使用的整數型別有：tinyint，smallint，mediumint，int，bigint。分別使用8,16,24,32,64位儲存空間。值範圍從-2^(N-1) 到 2^(N-1)-1，N為儲存空間位數。

整數型別可選unsigned屬性，表示不允許負值，正值範圍將提高一倍，但是儲存空間和效能和有符號是相同的。

另外，整數型別可以指定寬度，其實沒有多大意義，比如int(1)和int(20)範圍是相同的

實數型別

實數是帶小數部分的數字。然而，它們不只是為了儲存小數部分；也可以用decimal儲存比bigint還大的整數。

float和double型別支援使用標準的浮點運算進行近似計算，可能存在進度丟失

decimal用於儲存精確的小數，支援精確計算

浮點型別在儲存同樣範圍的值的時候，通常比decimal使用更少的空間，float4個，double8個位元組。因為需要額外的空間和計算開銷，所以應該儘量只在對小數進行精確計算的時候才使用decimal——比如財務資料，當然也可以將小數放大適當倍數轉為整數用bigint來儲存。

字串型別

1.char和varchar

varchar可變長度，需要1個或2個額外位元組記錄字串長度，小於等於225位元組是，使用1個位元組，否則2個位元組。比如varchar(10)需要11個位元組的儲存空間，varchar(1000)需要1002個。varchar節省了儲存空間，所以對效能也有幫助。

char固定長度，適合儲存很短的字串，或者所有值都接近同一個長度。例如，char非常適合儲存MD5值，因為它是一個定長的值。

2.blog和text

blog和text都是為儲存很大的 資料而設計的字串型別。blog採用二進位制儲存，沒有排序規則或字符集，text採用字元方式儲存，有排序規則和字符集

實際上，它們分別屬於兩組不同的資料型別家族：字元型別是tinytext，smalltext，text，mediumtext，longtext;對應的二進位制型別tinyblog，smallblog，blog，mediumblog，longblog。blog和smallblog是同義詞，text和smalltext是同義詞。

MySQL對blog和text列進行排序與其他型別不同：它只對最前max_sort_lenght位元組而不是整個字串做排序。

3.使用列舉enum代替字串型別（慎用）

有時候可以使用列舉型別代替常用的字串型別，比如性別、國家、民族等。MySQL儲存列舉是非常緊湊，會根據列值壓縮到一個或者兩個位元組中MySQL在內部會將每個值在列表中的位置保持為整數，並且在的.frm檔案中儲存“數字-字串”對映關係的“查詢表”。

列舉最不好的地方是字串列表是固定的，新增或刪除字串必須使用alter table，對於未來可能會改變的字串，使用列舉不是個好主意

日期和時間型別

1.datetime

能儲存大範圍的值，從1001到9999年，精度為秒，與時區無關，使用8位元組儲存空間

1.timestamp
儲存了從1970年1月1日午夜（格林尼治標準時間）以來的秒數，它和Unix時間戳相同。依賴時區，只使用4個位元組的儲存空間，因此範圍比datetime小的多：1970年到2038年。與其他資料型別不一樣，timestamp預設為not null

同時需要注意的是，由於在多個時區儲存或訪問資料造成時間不一致的問題。

關於alert table

alter table效能對於大表來說是個很大問題。MySQL執行大部分修改表結構的操作的方法是用新的結構建立一個空表，從舊錶中查出所有資料插入新表，然後刪除舊錶。如果記憶體不足而表有很大，而且還有很多索引，alert table可能花數個小時甚至數天才能完成。解決這個問題有兩個技巧：

1.先在一臺不提供服務的機器上執行alter table操作，然後和提供服務的主庫進行切換

2.“影子拷貝”，用要求的結構建立一張和原表無關聯的新表，然後通過重新命名和刪表操作交換兩張表。有很多工具可以幫我們完成這件事，不詳細介紹。