1. 良好的邏輯設計和物理設計是高性能的基石

1.1. 反範式的schema可以加速某些類型的查詢，但同時可能減慢其他類型的查詢

1.2. 添加計數器和彙總表是一個優化查詢的好方法，但它們的維護成本可能很

1.3. 將修改schema作為一個常見事件來規劃

2. 讓事情儘可能小而簡單是一個好主意

2.1. 儘量避免在設計中出現極端情況

2.2. 使用小的、簡單的、適當的數據類型，並避免使用NULL，除非確實是對真實數據進行建模的正確方法

2.3. 嘗試使用相同的數據類型來存儲相似或相關的值，尤其是在聯接條件中使用這些值時

2.4. 註意可變長度字元串，它可能會導致臨時表和排序的全長記憶體分配不樂觀

2.5. 如果可能的話，嘗試使用整數作為標識符

2.6. 小心使用ENUM和SET類型

2.7. 避免使用BIT類型

3. 選擇正確的數據類型對於獲得高性能至關重要

3.1. 更小的通常更好

3.1.1. 儘量使用能夠正確存儲和表示數據的最小數據類型

3.1.2. 更小的數據類型通常更快，因為它們占用的磁碟、記憶體和CPU緩存的空間更少，並且處理時需要的CPU周期也更少

3.1.3. 在schema中的多個地方增加數據類型範圍是一個痛苦且耗時的操作

3.1.4. 如果無法確定哪個數據類型是最好的，請選擇你認為不會超過的最小數據類型

3.2. 簡單為好

3.2.1. 簡單數據類型的操作通常需要更少的CPU周期

3.2.2. 整型數據比字元型數據的比較操作代價更低

3.2.2.1. 字元集和排序規則（collation）使字元型數據的比較更複雜

3.2.2.2. 應該將日期和時間存儲為MySQL的內置類型而不是字元串類型

3.2.2.3. 應該用整型數據存儲IP地址

3.3. 儘量避免存儲NULL

3.3.1. 最好指定列為NOT NULL，除非明確需要存儲NULL值

3.3.2. 如果查詢中包含可為NULL的列，對MySQL來說更難優化，因為可為NULL的列使得索引、索引統計和值比較都更複雜

3.3.3. 可為NULL的列會使用更多的存儲空間，在MySQL里也需要特殊處理

3.3.4. 可為NULL的列改為NOT NULL帶來的性能提升比較小

4. 整數類型

4.1. 整數（whole number）

4.1.1. TINYINT、SMALLINT、MEDIUMINT、INT或BIGINT

4.1.1.1. 使用8、16、24、32和64位存儲空間

4.1.2. 整數類型有可選的UNSIGNED屬性，表示不允許負值，這大致可以使正數的上限提高一倍

4.1.3. 有符號和無符號類型使用相同的存儲空間，並具有相同的性能，因此可以根據數據實際範圍選擇合適的類型

4.1.4. 整數計算通常使用64位的BIGINT整數

4.1.5. 對於存儲和計算來說，INT（1）和INT（20）是相同的

4.1.6. 一些大容量的場景，可以考慮使用BIGINT代替DECIMAL，將需要存儲的貨幣單位根據小數的位數乘以相應的倍數即可

4.1.7. 存儲財務數據並精確到萬分之一分，則可以把所有金額乘以一百萬，然後將結果存儲在BIGINT里

4.1.8. 同時避免浮點存儲計算不精確和DECIMAL精確計算代價高的問題

4.2. 實數（real number，帶有小數部分的數字）

4.2.1. 不僅適用於帶小數的數字，也可以使用DECIMAL存儲比BIGINT還大的整數

4.2.2. 浮點類型通常比DECIMAL使用更少的空間來存儲相同範圍的值

4.2.3. FLOAT列使用4位元組的存儲空間

4.2.4. DOUBLE占用8位元組，比FLOAT具有更高的精度和更大的值範圍

4.2.5. 應該儘量只在對小數進行精確計算時才使用DECIMAL

5. 字元串類型

5.1. 字元串長度定義的不是位元組數，是字元數

5.2. VARCHAR

5.2.1. 用於存儲可變長度的字元串，是最常見的字元串數據類型

5.2.2. 它比固定長度的類型更節省空間，因為它僅使用必要的空間

5.2.3. 更少的空間用於存儲更短的值

5.2.4. 需要額外使用1或2位元組記錄字元串的長度

5.2.4.1. VARCHAR（1000）的列則需要1002個位元組，因為需要2位元組存儲長度信息

5.2.5. 節省了存儲空間，所以對性能也有幫助

5.2.5.1. 由於行是可變長度的，在更新時可能會增長，這會導致額外的工作

5.2.6. 推薦使用場景

5.2.6.1. 字元串列的最大長度遠大於平均長度

5.2.6.2. 列的更新很少，所以碎片不是問題

5.2.6.3. 使用了像UTF-8這樣複雜的字元集，每個字元都使用不同的位元組數進行存儲

5.3. CHAR

5.3.1. 總是為定義的字元串長度分配足夠的空間

5.3.2. 當存儲CHAR值時，MySQL刪除所有尾隨空格

5.3.3. 如果需要進行比較，值會用空格填充

5.3.4. 推薦使用場景

5.3.4.1. 存儲非常短的字元串

5.3.4.1.1. 對於非常短的列，CHAR也比VARCHAR更高效

5.3.4.1.2. 設計為只保存Y和N的值的CHAR（1）在單位元組字元集中只使用1位元組，但VARCHAR（1）需要2位元組，因為還有一個記錄長度的額外位元組

5.3.4.2. 所有值的長度都幾乎相同的情況

5.3.5. 對於經常修改的數據，CHAR也比VARCHAR更好，因為固定長度的行不容易出現碎片

5.4. 二進位字元串與常規字元串非常相似，但它們存儲的是位元組而不是字元

5.5. 填充也不同：MySQL填充BINANRY用的是\0（零位元組）而不是空格，並且在檢索時不會去除填充值

5.6. 位元組比較的優勢

5.6.1. 大小寫不敏感

5.6.2. 二進位比較比字元比較簡單得多，因此速度更快

5.7. BLOB和TEXT類型

5.7.1. 存儲很大的數據而設計的字元串數據類型，分別採用二進位和字元方式存儲

5.7.2. 字元類型

5.7.2.1. TINYTEXT、SMALLTEXT、TEXT、MEDIUMTEXT和LONGTEXT

5.7.2.2. TEXT是SMALLTEXT的同義詞。

5.7.2.3. 有字元集和排序規則

5.7.3. 二進位類型

5.7.3.1. TINYBLOB、SMALLBLOB、BLOB、MEDIUMBLOB、LONGBLOB

5.7.3.2. BLOB是SMALLBLOB的同義詞

5.7.3.3. 二進位數據，沒有排序規則或字元集

5.7.3.4. 如果需要在檢索後保持值不變，請小心使用BINARY類型，MySQL會使用\0將其填充到需要的長度

5.7.4. 當BLOB和TEXT值太大時，InnoDB會使用獨立的“外部”存儲區域，此時每個值在行內需要1～4位元組的存儲空間，然後在外部存儲區域需要足夠的空間來存儲實際的值

5.7.5. 只對這些列的最前max_sort_length位元組而不是整個字元串做排序

5.7.6. 不能將BLOB和TEXT數據類型的完整字元串放入索引，也不能使用索引進行排序