MYSQL 最佳化指南

標籤：

 資料庫設計原則 標準化和正常化 資料庫設計範式(3NF) 第一範式

資料屬性唯一標示

在任何一個關聯式資料庫中，第一範式（1NF）是對關係模式的基本要求，不滿足第一範式（1NF）的資料庫就不是關聯式資料庫。 
所謂第一範式（1NF）是指資料庫表的每一列都是不可分割的基本資料項目，同一列中不能有多個值，即實體中的某個屬性不能有多個值或者不能有重複的屬性。如果出現重複的屬性，就可能需要定義一個新的實體，新的實體由重複的屬性構成，新實體與原實體之間為一對多關聯性。在第一範式（1NF）中表的每一行只包含一個執行個體的資訊。例如，對於圖3-2 中的員工資訊表，不能將員工資訊都放在一列中顯示，也不能將其中的兩列或多列在一列中顯示；員工資訊表的每一行只表示一個員工的資訊，一個員工的資訊在表中只出現一次。簡而言之，第一範式就是無重複的列。

 第二範式

行資訊唯一標示 
第二範式（2NF）是在第一範式（1NF）的基礎上建立起來的，即滿足第二範式（2NF）必須先滿足第一範式（1NF）。第二範式（2NF）要求資料庫表中的每個執行個體或行必須可以被唯一地區分。為實現區分通常需要為表加上一個列，以儲存各個執行個體的唯一標識。 
員工資訊表中加上了員工編號（emp_id）列，因為每個員工的員工編號是唯一的，因此每個員工可以被唯一區分。這個唯一屬性列被稱為主關鍵字或主鍵、主碼。 
第二範式（2NF）要求實體的屬性完全依賴於主關鍵字。所謂完全依賴是指不能存在僅依賴主關鍵字一部分的屬性，如果存在，那麼這個屬性和主關鍵字的這一部分應該分離出來形成一個新的實體，新實體與原實體之間是一對多的關係。為實現區分通常需要為表加上一個列，以儲存各個執行個體的唯一標識。簡而言之，第二範式就是非主屬性非部分依賴於主關鍵字。

 第三範式

資訊資料唯一儲存 
滿足第三範式（3NF）必須先滿足第二範式（2NF）。簡而言之，第三範式（3NF）要求一個資料庫表中不包含已在其它表中已包含的非主關鍵字資訊。例如，存在一個部門資訊表，其中每個部門有部門編號（dept_id）、部門名稱、部門簡介等資訊。那麼在圖3-2的員工資訊表中列出部門編號後就不能再將部門名稱、部門簡介等與部門有關的資訊再加入員工資訊表中。如果不存在部門資訊表，則根據第三範式（3NF）也應該構建它，否則就會有大量的資料冗餘。簡而言之，第三範式就是屬性不依賴於其它非主屬性。 
滿足第三範式的條件： 
若關係R中存在非平凡FD A1A2A3……An->B,且要麼左邊{A1A2A3……An}是超鍵，要麼右邊的B屬於某個鍵，則認為關係R屬於第三範式(3NF).

 反範式設計

資料庫設計要嚴格遵守範式，這樣設計出來的資料庫，雖然思路很清晰，結構也很合理，但是，有的時候，卻要在一定程度上打破範式設計。 
這裡其實並不矛盾，因為範式越高，設計出來的表可能越多，關係可能越複雜，但是效能卻不一定會很好，因為表一多，就增加了關聯性。這一點表現得很明顯。 
最明顯的打破範式的設計方法就是冗餘法，以空間換取時間的做法，把資料冗餘在多個表中，當查詢時可以減少或者是避免表之間的關聯。

 資料驅動

採用資料驅動而非硬式編碼方式，許多策略變更和維護都會方便得多，大大增強系統的靈活性和擴充性。 
舉例，假如使用者介面要訪問外部資料源（檔案、XML 文檔、其他資料庫等），不妨把相應的串連和路徑資訊儲存在使用者介面支援表裡。還有，如果使用者介面執行工作流程之類的任務（發送郵件、列印信箋、修改選項組等），那麼產生工作流程的資料也可以存放在資料庫裡。角色許可權管理也可以通過資料驅動來完成。事實上，如果過程是資料驅動的，你就可以把相當大的責任推給使用者，由使用者來維護自己的工作流程過程。

 考慮各種變化和記錄資料的基本資料

在設計資料庫的時候考慮到哪些資料欄位將來可能會發生變更。 
舉例 資料的添加時間,更新時間 使用者的註冊ip和登入ip等

 資料庫建立 資料庫表名

1. 表名應具有描述性，杜絕一切拼音或拼音英文混雜的命名方式
2. 表名運行使用字母，數字和底線，不允許使用其他字元。表名使用單詞開頭，不運行使用數字和底線開頭
3. 表名一律有統一首碼，首碼表名之間底線連結。使用首碼可以讓同一項目在一個庫中安裝多個。
4. 表名單詞一律小寫，單詞之間使用底線連結
5. 表名長度不能超過64個字元
6. 所有資料表名稱，只要其名稱是可數名詞，則建議以複數方式命名，例如：xs_users（使用者表）
7. 表名要迴避MySQL的保留字

 資料庫表欄位名

1. 欄位名應具有描述性，杜絕一切拼音或拼音英文混雜的命名方式
2. 欄位名允許使用字母、數字和底線，不允許使用其他字元。欄位名鼓勵使用與所在表的內容相關單詞開頭，允許但不鼓勵使用數字和其他字元開頭。
3. 欄位名一律小寫，單詞之間使用底線連結。
4. 欄位名長度不能超過64個字元
5. 字元類型和長度在不同資料表中必須保證一致性，不允許出現同一欄位在一個表中為整型但在另外一個表中為字元型的情況。
6. 當幾個表間的欄位有關連時，要注意表與表之間關連欄位命名的統一，如xs_orders表中的uid與xs_carts表中的uid，都儲存有xs_users表中的id。
7. 儲存多項內容的欄位或代表數量的欄位，也應當以複數方式明明，例如views
8. 每個表都建議有一個代表id自增量的欄位，可使用全稱的形式，也可以只將其命名為id

 欄位索引名稱

1. 索引名稱允許使用字母、數字和底線，不允許使用其他字元
2. 對任何外鍵採用非成組索引
3. 不要索引text/blob類型的欄位，不索引字元過多的欄位
4. 根據業務需求建立複合式索引
5. 索引長度不能超過64個字元
6. 頻繁進行資料操作的表，不要建立太多的索引

 欄位結構

進行表結構設計時，應當做到恰到好處，反覆推敲，從而實現最優的資料存放區體系 短小 精悍

1. NULL值的欄位，資料庫在進行比較操作時，會先判斷其是否為NULL，非NULL時才進行值的比對。因此基於效率的考慮，所有欄位均不可為空，即全部使用NOT NULL的屬性修飾欄位；
2. 如果不會使用儲存非負數的欄位，必須設定為unsigned類型，能獲得範圍大一倍的數值儲存空間
3. 任何類型的資料表，欄位空間應當本著足夠用、不浪費的原則
4. 個別欄位類型在資料結構設計的時候需要注意：enum枚舉類型由tinyint類型代替
5. 包含任何varchar、text等變長欄位的資料表，即為變長表，反之為定長表。在設計表結構時如果能夠使用定長資料類型，盡量用定長的，因為定長表的查詢、檢索、更新速度都很快。必要時可以把部分關鍵的、承擔頻繁訪問的表拆分，例如定長資料一個表，非定長資料一個表。
6. 更小的欄位類型永遠比更大的欄位類型處理要快得多。對於字元型，其處理時間與字串長度直接相關。一般情況下，較小的表處理更快。對於定長表，應該選擇較小的類型，只要能儲存夠節省空間的。一個text類型的值用2位元組記錄值的長度，而一個longtext則用4位元組記錄其值的長度。如果儲存的值的長度不超過64kb，
7. 數值運算一般比字元運串更快，例如比較運算，可在單一運算中對數進行比較。而串運算設計幾個逐步位元組的比較，如果穿更長，這種比較要更多。如果字串列的數值數目有限，應該利用普通整型來獲得數值運算的優越性。

 SQL最佳化 最佳化目標

減少 IO 次數,IO永遠是資料庫最容易瓶頸的地方，這是由資料庫的職責所決定的，大部分資料庫操作中超過90%的時間都是 IO 操作所佔用的，減少 IO 次數是 SQL 最佳化中需要第一優先考慮，當然，也是收效最明顯的最佳化手段。 
降低 CPU 計算,除了 IO 瓶頸之外，SQL最佳化中需要考慮的就是 CPU 運算量的最佳化了。order by, group by,distinct … 都是消耗 CPU 的大戶(這些操作基本上都是 CPU 處理記憶體中的資料比較運算)。當我們的 IO 最佳化做到一定階段之後，降低 CPU 計算也就成為了我們 SQL 最佳化的重要目標

 常見誤區 count(1)和count(primary_key) 優於 count(*)

很多人為了統計記錄條數，就使用 count(1) 和 count(primary_key) 而不是 count() ，他們認為這樣效能更好，其實這是一個誤區。對於有些情境，這樣做可能效能會更差，應為資料庫對 count() 計數操作做了一些特別的最佳化。

 count(column) 和 count(*) 是一樣的

這個誤區甚至在很多的資深工程師或者是 DBA 中都普遍存在，很多人都會認為這是理所當然的。實際上，count(column) 和 count() 是一個完全不一樣的操作，所代表的意義也完全不一樣。 
count(column) 是表示結果集中有多少個column欄位不為空白的記錄 
count() 是表示整個結果集有多少條記錄

 select a,b from … 比 select a,b,c from … 可以讓資料庫訪問更少的資料量

這個誤區主要存在於大量的開發人員中，主要原因是對資料庫的儲存原理不是太瞭解。 
實際上，大多數關係型資料庫都是按照行(row)的方式儲存，而資料存取操作都是以一個固定大小的IO單元(被稱作 block 或者 page)為單位，一般為4KB，8KB… 大多數時候，每個IO單元中儲存了多行，每行都是儲存了該行的所有欄位(lob等特殊類型欄位除外)。 
所以，我們是取一個欄位還是多個欄位，實際上資料庫在表中需要訪問的資料量其實是一樣的。 
當然，也有例外情況，那就是我們的這個查詢在索引中就可以完成，也就是說當只取 a,b兩個欄位的時候，不需要回表，而c這個欄位不在使用的索引中，需要回表取得其資料。在這樣的情況下，二者的IO量會有較大差異。

 order by 一定需要排序操作

我們知道索引資料實際上是有序的，如果我們的需要的資料和某個索引的順序一致，而且我們的查詢又通過這個索引來執行，那麼資料庫一般會省略排序操作，而直接將資料返回，因為資料庫知道資料已經滿足我們的排序需求了。 
實際上，利用索引來最佳化有排序需求的 SQL，是一個非常重要的最佳化手段 
延伸閱讀:http://blog.csdn.net/zzxian/article/details/7927810

 基本原則 盡量少使用外部索引鍵關聯

資料庫的諸多設計，帳號，許可權，約束，觸發器，都是為 C/S 結構設計的，是以 C 端不可信做為假設前提的。B/S 模式安全邊界前移到 web 服務層，應用與資料庫之間是可信的，應用自行完成這些功能更加靈活。

 盡量少 join

MySQL 的優勢在於簡單，但這在某些方面其實也是其劣勢。MySQL 最佳化器效率高，但是由於其統計資訊的量有限，最佳化器工作過程出現偏差的可能性也就更多。對於複雜的多表 Join，一方面由於其最佳化器受限，再者在 Join 這方面所下的功夫還不夠，所以效能表現離 Oracle 等關係型資料庫前輩還是有一定距離。但如果是簡單的單表查詢，這一差距就會極小甚至在有些情境下要優於這些資料庫前輩。

 盡量避免 select *

很多人看到這一點後覺得比較難理解，上面不是在誤區中剛剛說 select 子句中欄位的多少並不會影響到讀取的資料嗎? 是的，大多數時候並不會影響到 IO 量，但是當我們還存在 order by 操作的時候，select 子句中的欄位多少會在很大程度上影響到我們的排序效率。此外，上面誤區中不是也說了，只是大多數時候是不會影響到 IO 量，當我們的查詢結果僅僅只需要在索引中就能找到的時候，還是會極大減少 IO 量的。

 盡量用 join 代替子查詢

雖然 Join 效能並不佳，但是和 MySQL 的子查詢比起來還是有非常大的效能優勢。MySQL 的子查詢執行計畫一直存在較大的問題，雖然這個問題已經存在多年，但是到目前已經發布的所有穩定版本中都普遍存在，一直沒有太大改善。雖然官方也在很早就承認這一問題，並且承諾儘快解決，但是至少到目前為止我們還沒有看到哪一個版本較好的解決了這一問題。 
MYSQL 5.6已經最佳化子查詢 http://www.linuxidc.com/Linux/2012-08/67606.htm

 盡量少 or

當 where 子句中存在多個條件以“或”並存的時候，MySQL 的最佳化器並沒有很好的解決其執行計畫最佳化問題，再加上 MySQL 特有的 SQL 與 Storage 分層架構方式，造成了其效能比較低下，很多時候使用 union all 或者是union(必要的時候)的方式來代替“or”會得到更好的效果。

 盡量用 union all 代替 union

union 和 union all 的差異主要是前者需要將兩個(或者多個)結果集合并後再進行唯一性過濾操作，這就會涉及到排序，增加大量的 CPU 運算，加大資源消耗及延遲。所以當我們可以確認不可能出現重複結果集或者不在乎重複結果集的時候，盡量使用 union all 而不是 union。 
擴充閱讀: http://jingyan.baidu.com/article/2d5afd69e8dfd285a3e28e66.html

 盡量早過濾

這一最佳化策略其實最常見於索引的最佳化設計中(將過濾性更好的欄位放得更靠前)。 
在 SQL 編寫中同樣可以使用這一原則來最佳化一些 Join 的 SQL。比如我們在多個表進行分頁資料查詢的時候，我們最好是能夠在一個表上先過濾好資料分好頁，然後再用分好頁的結果集與另外的表 Join，這樣可以儘可能多的減少不必要的 IO 操作，大大節省 IO 操作所消耗的時間。

 避免類型轉換

這裡所說的“類型轉換”是指 where 子句中出現 column 欄位的類型和傳入的參數類型不一致的時候發生的類型轉換： 
人為在column_name 上通過轉換函式進行轉換直接導致 MySQL(實際上其他資料庫也會有同樣的問題)無法使用索引，如果非要轉換，應該在傳入的參數上進行轉換由資料庫自己進行轉換 
如果我們傳入的資料類型和欄位類型不一致，同時我們又沒有做任何類型轉換處理，MySQL 可能會自己對我們的資料進行類型轉換操作，也可能不進行處理而交由儲存引擎去處理，這樣一來，就會出現索引無法使用的情況而造成執行計畫問題。

 優先最佳化高並發的 SQL，而不是執行頻率低某些“大”SQL

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

 從全域出發最佳化，而不是片面調整

SQL 最佳化不能是單獨針對某一個進行，而應充分考慮系統中所有的 SQL，尤其是在通過調整索引最佳化 SQL 的執行計畫的時候，千萬不能顧此失彼，因小失大。

 儘可能對每一條運行在資料庫中的SQL進行 explain

最佳化 SQL，需要做到心中有數，知道 SQL 的執行計畫才能判斷是否有最佳化餘地，才能判斷是否存在執行計畫問題。在對資料庫中啟動並執行 SQL 進行了一段時間的最佳化之後，很明顯的問題 SQL 可能已經很少了，大多都需要去發掘，這時候就需要進行大量的 explain 操作收集執行計畫，並判斷是否需要進行最佳化。

 專題 MYSQL的查詢、子查詢及串連查詢

http://www.cnblogs.com/rollenholt/archive/2012/05/15/2502551.html

 MYSQL大資料量的初步最佳化方案:

mysql只做簡單的事情，千萬級的表，不論如何最佳化，同樣的SQL都沒有十萬級的表訪問快。 
如果設計大表，要問自己幾個問題： 
1.資料庫分庫 摘除資料表之間的關聯 
1.水平分表/mysql分區 
1.垂直分割

MYSQL 最佳化指南