mysql優化（一）

建表原則

• 定長與變長分離

如id int,佔4個字節，char(4)佔4個字符長度，也是定長，time
即每一個單元值佔的字節是固定的。
核心且經常使用字段宜建成定長放在一張表，而varchar，text，blob這種變長字段適合單放一張表，用主鍵與核心表關聯起來

• 經常使用字段與不經常使用字段要分離

需結合網站的具體業務來分析，分析字段的查詢場景，查詢頻率低的字段單獨拆出來

• 在一對多須要關聯統計的字段上添加冗餘字段

如select count(b.*) from a left join b on a.id=b.aid where a.id=1這種查詢宜在a表直接創建統計字段，有新增就加一，而不是經過關聯查詢

---

列選擇原則

1. 字段類型優先級

整形 > date、time > enum、char > varchar > blob、text
列的特色分析：

整形：定長，沒有國家/地區之分，沒有字符集的差別
好比tinyint 1，2，3，4，5和char(1) 1，2，3，4，5，從空間上都是佔1字節，但order by前者更快，由於後者要考慮字符集（如utf8）與校對集（就是排序規則）
time：定長、運算快、節省空間；考慮時區，寫sql不方便
enum：枚舉類型，內部用整型來存儲，能起到約束值的目的。但與char聯查時，內部要經歷串與值的轉化
char：定長，考慮字符集和校對集
varchar：不定長，要考慮字符集的轉換和排序時的校對集，速度慢
text/blob：沒法使用內存臨時表（排序等操做只能在磁盤上進行）

1. 夠用就行，不要慷慨

大的字段浪費內存，影響速度；以年齡爲例tinyint unsigned not null，能夠存儲255歲，用int的話就浪費了3個字節；又好比varvhar(10)和varvhar(255)存儲相同內容，看似varchar由於變長佔用相同，但在表聯查時varvhar(255)要花更多內存

1. 儘可能不實用null

緣由：null不利於索引，要用特殊的字節來標註，在磁盤上佔據的空間其實更大