資料型別
簡單的原則：
1）更小的通常最好
why：更小的資料型別會占用更小的磁碟，記憶體和cpu快取，會產生更小的索引，處理時cpu週期更少。
2）簡單就好
整數好於字串。
why：整型比字元操作代價更低，因為字符集的排序規則使字元比較比整型比較更複雜。
3）盡量避免null值
如何儲存null值，索引如何處理null值？
選擇資料型別時，先選擇大型別，再選擇具體型別。
1、整數型別
tinyint、smallint、mediumint、int、bigint
可選屬性：unsigned
2、實數型別
float、double、decimal
比較：float和double使用cpu的原生浮點運算，運算更快，但是計算不精確。decimal支援更大的範圍，精度高。
怎麼避免浮點儲存運算的不精確和decimal精確計算代價高的問題？使用bigint
3、字串型別
varchar與char比較：
1）varchar在以下情況是適合的：字串列的最大長度比平均長度大得多；列的更新少，碎片不是問題；使用了utf-8等複雜字符集，每個字元使用不同的位元組數。
2）char在以下情況是適合的：很短的字串；所有的值都接近同乙個長度；經常變更的資料。
3）儲存char值時，mysql伺服器層會刪除所有的末尾空格，所以取出時會發現空格不在了。varchar不會存在這種問題。
4）用varchar(5)和varchar(200)存'hello'時空間開銷一致，使用更短的列有什麼優勢？可變字串在臨時表和排序時可能導致悲觀的按最大長度分配記憶體。
binary和varbinary：
1）用於二進位制資料，儲存的是位元組碼而不是字元
2）mysql填充binary採用的是\0而不是空格，在檢索時不會去掉填充值。
blob和text
1）用於儲存很大的資料，分別採用二進位制和字元方式儲存。
2）mysql對blob和text列進行排序時怎麼樣的？
3）memory不支援blob，text型別。所以查詢使用了blob或text列並且需要使用隱式臨時表時，將不得不使用myisam磁碟臨時表。怎麼辦？避免使用這些型別，沒法避免的話用substring(column,length)
enum
1）可用於代替常用的字串型別，原理是在表檔案.frm中儲存"數字-字串「的對映關係。
2）優點？壓縮位元組；列轉換為列舉後，關聯更快；字串主鍵轉換為列舉後，innodb會使非主鍵索引更小。
3）缺點？新增或刪除列舉值時必須使用alter table。
4）char/varchar與列舉進行關聯時的效能？關聯時盡量使用相同型別的列。
4、日期和時間型別
datetime：8個位元組，不依賴時區，範圍為1001-2023年。
timestamp：4個位元組，會根據時區變化，範圍為1970-2023年。盡量使用。
5、位資料型別
bit ：避免使用
set：小心使用
6、主鍵的資料型別
整數型別：最好
enum和set型別：通常是糟糕的選擇。
字串型別：避免，消耗空間，慢。「隨機」字串。
表設計陷阱
1）太多的列。為什麼？主要是因為轉換代價，儲存引擎層提供行快取給伺服器層，伺服器曾需要將編碼過的列轉換成行資料結構，對於myisam的變長行和innodb的行總是要轉換的。
2）太多的關聯。
3）過多使用列舉。因為修改列舉列表時，會做一次alter table操作。
4）列型別預設可為null，應盡可能的避免為null，用空格，0，特殊值能代替嗎？
正規化和反正規化
正規化：每個事實資料會出現並且只出現一次
反正規化：資訊是冗餘的。
正規化的優缺點？
1）優：更新比反正規化快。很少需要distinct或group by。只需修改更少的資料。表很小能放在記憶體中，執行更快。
2）缺：需要關聯
反正規化的優缺點？
1）優：避免關聯。
2）缺：
應該根據實際情況，混用正規化和反正規化。
快取表和彙總表
快取表：儲存那些可以比較簡單地從其他表獲取（但是每次獲取的速度比較慢）資料的表，邏輯上冗餘。
彙總表：使用group by語句聚合資料的表，邏輯上不冗餘。
加快alter table操作的速度
修改表大部分情況下，會鎖住表並且重建整張表。怎麼改進？一是在備庫修改，再切換為主庫；二是「影子拷貝」。
Mysql 表結構優化
一 資料型別的選擇 簡單規則 1 字元長度設定更小更好 2 型別越簡單越好，越簡單使用的cpu越少 比如儲存時間字段採用varchar型別與datatime型別對比 3 盡量避免使用null 因為可為null的列使得索引 索引統計和值比較都更加複雜 實際細節 1 整型 tinyint，smallin...
MySQL優化四（優化表結構）
昨晚吃吃喝喝的太多，熬夜到凌晨二點。今天頭髮雜亂，臉龐憔悴，像是吸毒了。下午去買衣服，肚子一看大了不少。奈何女朋友還沒有乙個，就已經發福了。管不住口，邁不開腿。一 優化表結構 1.盡量將表字段定義為not null約束，這時由於在mysql中含有空值的列很難進行查詢優化，null值會使索引以及索引的...
MySQL效能優化之表結構優化
第一正規化 屬性 字段 的原子性約束，要求屬性具有原子性，不可再分割 第二正規化 記錄的惟一性約束，要求記錄有惟一標識，每條記錄需要有乙個屬性來做為實體的唯一標識。第三正規化 屬性 字段 冗餘性的約束，即任何字段不能由其他字段派生出來。外來鍵解決設計原則 在資料冗餘和處理速度之間找到合適的平衡點 資...