MySQL資料型別和Schema優化（二）

schema設計

快取表和彙總表

良好的邏輯設計與物理設計是高效能的基石，應該根據具體業務需求的查詢語句來設計schema，這往往需要權衡各種因素。

比如，反正規化的設計可能會增加某些查詢的速度，但也會帶來資料同步的維護工作。

mysql支援的資料型別非常多，選擇合適的資料型別將有助於mysql的效能提公升。

一般遵循以下規則：

更小的資料型別

簡單的資料型別

盡量避免null

更小的資料型別，意味著占用更小的磁碟、記憶體、cpu快取等，當然乙個比較重要的前提是對型別要有合理的預估，畢竟對型別的變更是一項痛苦的事情，alter table操作會鎖住整個表。

簡單的資料型別，意味著mysql更少的處理，占用更少的cpu週期，比如整型比字串操作代價更低，字串需要處理字符集和校對規則(排序規則)，使得字串的處理更加複雜。

盡量避免null，如果沒有指定列是否為null，mysql預設設定列為null。一般可以的話推薦設定not null，因為使用null對於mysql更難優化。當為null的列被索引時，每個索引記錄需要乙個額外的位元組。

注意：timesamp時區問題，可能會導致cpu耗盡。前提是設定time_zone=system，該設定會獲取系統的時區配置，並且獲取操作是全域性鎖，高併發的情況下會導致cpu耗盡。

tinyint、smallint、mediumint、int、bigint

department

employee

leadera小明

王總a小李王總

當需要修改部門領導時，需要更新兩條資料，如果遵循正規化化，再新增乙個部門和領導的實體表，則只需要更新一條資料即可同時可以避免一些group by，distinct等操作，比如上面案例需要統計所有部門，就需要通過group by操作。

正規化化的缺點是需要多表關聯，稍微複雜一點可能就需要關聯才能查詢，此時可能會通過一些反正規化的手段，減少關聯查詢。常用的做法就是在另乙個表，儲存相同的列。

通常設計是混用模式：正規化+反正規化配合使用

快取表和彙總表沒有標準的定義，通常來說快取表來表示儲存那些可以比較簡單地從其他表schema獲取（但是每次獲取比較慢），可以通過快取冗餘資料，避免從其他表查詢。

彙總表可以優先計算出結果，直接使用簡單方式進行查詢，減少實時查詢計算的效能問題。