性能優化：完成某件任務所需的時間度量。
性能剖析
性能剖析是測量和分析時間花費在哪裏的主要方法。性能剖析一般有兩個步驟：測量任務所花費的時間；然後對結果進行統計和排序，將重要的任務排到前面。
性能剖析工具
show status、show profile、檢查慢查詢日誌的條目、show processlist;
性能低下的原因
資源被過度使用，餘量已經不足以正常工作；
資源沒有被正確配置；
資源已經被損壞或者失靈；
數據類型
數字類型
tinyint smallint mediumint int bigint decimal float double
字符類型
char varchar
BLOB和TEXT類型
BLOB類型存儲的是二進制數據，沒有排序規則或字符集，而TEXT類型由字符集和排序規則
日期和時間類型
DATETIME和TIMESTAMP
位數據類型
BIT和SET
範式的優缺點
範式化的更新操作比反範式化要快；
當數據比較好地範式化時，就只有很少或者沒有重複數據，所以只需要更改更少的數據；
範式化的表通常更小，可以更好地放在內存裏，所以執行操作會更快；
很少由多餘的數據意味着檢索列表數據時更少需要DISTINCT或者GROUP BY語句。
範式化設計通常需要關聯。
數據庫設計原則
儘量比賣你過度設計；
使用小而簡單的合適數據類型，除非真實數據模型中由確切的需要，否則應該儘可能地避免使用NULL值；
儘量使用相同的數據類型存儲相似或相關的值，尤其是要在關聯條件中使用的列；
注意可變長字符串，其在臨時表和排序時可能導致悲觀的按最長長度分配內存；
儘量使用整型定義標識列；
避免使用MySQL已經遺棄的特性；
小心使用ENUM和SET。
索引優化
B-Tree：適用於全鍵值、鍵值範圍或鍵前綴查找。其中鍵前綴查找只適用於根據最左前綴的查找。使用場景：全值匹配、匹配最左前綴、匹配列前綴、匹配範圍值、精確匹配某一列並範圍匹配另外一列、只訪問索引的查詢；
B-tree的限制：如果不是按照索引的最左列開始查找，則無法使用索引。不能體哦愛國索引中的列；如果查詢中由某個列的範圍查詢，則其右邊所有列都無法使用索引優化查找。
哈希索引（hash index）：基於哈希表實現，只有精確匹配索引列的查詢纔有效。
哈希索引的限制：哈希索引只包含哈希值和行指針，而不存儲字段值，所以不能使用索引中的值來避免讀取行。不過，訪問內存中的速度很快，所以大部分情況下這一點對性能的影響並不明顯；哈希索引數據並不是按照索引值順序排序存儲的，所以無法用於排序；哈希索引也不支持部分索引列匹配查找，因爲哈希索引始終是使用索引列的全部內容來計算哈希值的；哈希索引支持等值比較查詢；訪問哈希索引的數據非常快，除非有很多哈希衝突，當有哈希衝突時，存儲引擎必須遍歷鏈表中所有的行指針，逐行進行比較，直到找到所有符合條件的行；如果哈希衝突有很多的話，一些索引維護操作的代價也很高。
索引的有點：索引可以大大減少放服務器需要掃描的數據量；索引可幫助服務器避免排序和臨時表；索引可以將隨機I/O變爲順序I/O。
索引統計的成本：
Memory引擎根本不存在索引統計信息；
MyISAM將索引統計信息存儲在磁盤中，ANALYZE TABLE需要進行一次全索引掃描來計算索引基數；
知道MySQL5.5版本，InnoDB也不在磁盤存儲索引統計信息，而是通過隨機的索引訪問進行評估並將其存儲在內存中。
查詢優化
查詢的生命週期：從客戶端，到服務器，在服務器上面解析，生成執行計劃，執行，並返回結果給客戶端。
查詢性能低下的基本原因：訪問的數據太多；
分析方法：確認應員工程序是否在索引大量超過需要的數據。這意味着訪問了太多的行，但有時候也有可能訪問了太多的列；
確認MySQL服務器曾是否在分析大量超過需要的數據行。
查詢需要掃描大量的數據但只返回少數的行，那麼通常可以嘗試下面的技巧區優化它：
使用索引覆蓋掃描，把所有需要用的列都放到索引中，這樣存儲引擎無須回表獲取對應行就可以返回結果。
改變庫表結構；
重寫這個複雜的查詢。
客戶端發送一條查詢給服務器；
服務器先檢查查詢緩存，如果命中了緩存，則立刻返回存儲在緩存中的結果。否則進入下一階段；
服務器進行SQL解析、預處理，再由優化器生成對應的執行計劃；
MySQL根據優化器生成的執行計劃，調用存儲引擎的api來執行查詢；
將結果返回給客戶端。
優化方式：
重新定義關聯表的順序；
將外連接轉化爲內連接；
使用等價變換規則；
優化COUNT()、MIN()、MAX()；
預估並轉化常量表達式；
覆蓋索引掃描；
子查詢優化；
提前終止查詢；
等值傳播；
列表IN（）的比較；