MySQL 建表的優化戰略 小結。本站提示廣大學習愛好者：（MySQL 建表的優化戰略 小結）文章只能為提供參考，不一定能成為您想要的結果。以下是MySQL 建表的優化戰略 小結正文
目次
1. 字符集的選擇 1
2. 主鍵 1
3. 外鍵 2
4. 索引 2
4.1. 以下情形合適於創立索引 2
4.2. 以下的情形下不合適創立索引 3
4.3. 結合索引 3
4.4. 索引長度 4
5. 特別字段 4
5.1. 冗余字段 4
5.2. 朋分字段 4
5.3. BLOB和CLOB 5
6. 特別 5
6.1. 表格朋分 5
6.2. 應用非事務表類型 5
1. 字符集的選擇
假如確認全體是中文，不會應用多說話和中文沒法表現的字符，那末GBK是首選。
采取UTF-8編碼會占用3個字節，而GBK只須要2個字節。
2. 主鍵
盡量應用長度短的主鍵
體系的自增類型AUTO_INCREMEN, 而不是應用相似uuid()等類型。假如可使用外鍵做主鍵，則更好。好比1：1的關系，應用主表的id作為從表的主鍵。
主鍵的字段長度須要依據須要指定。
tinyint 從 2的7次方-1 ：-128 到 127
smallint 從 2的15次方-1 ：-32768 到 32767
mediumint 表現為 2的23次方-1： 從 -8388608 到8388607
int 表現為 2的31次方-1
bigint 表現為 2的63次方-1
在主鍵上無需建零丁的索引，由於體系外部為主鍵樹立了聚簇索引。
許可在其它索引上包括主鍵列。
3. 外鍵
外鍵會影響拔出和更新機能，關於批量靠得住數據的拔出，建議先屏障外鍵檢討。
關於數據量年夜的表，建議去失落外鍵，改由運用法式停止數據完全性檢討。
盡量用選用對應主表的主鍵作作為外鍵，防止選擇長度很年夜的主表獨一鍵作為外鍵。
外鍵是默許加上索引的
4. 索引
創立索引，要在恰當的表，恰當的列創立恰當數目的恰當索引。在查詢優先和更新優先之間做均衡。
4.1. 以下情形合適於創立索引
在常常須要搜刮的列上，可以加速搜刮的速度
在作為主鍵的列上，強迫該列的獨一性和組織表中數據的分列構造
在常常用在銜接的列上，這些列重要是一些外鍵，可以加速銜接的速度
在常常須要依據規模停止搜刮的列上創立索引，由於索引曾經排序，其指定的規模是持續的
在常常須要排序的列上創立索引，由於索引曾經排序，如許查詢可以應用索引的排序，加速排序查詢時光
在常常應用在WHERE子句中的列下面創立索引，加速前提的斷定速度。
4.2. 以下的情形下不合適創立索引
關於那些在查詢中很少應用或許參考的列不該該創立索引。這是由於，既然這些列很少應用到，是以有索引或許無索引，其實不能進步查詢速度。相反，因為增長了索引，反而下降了體系的保護速度和增年夜了空間需求。
關於那些只要很多數據值的列也不該該增長索引。這是由於，因為這些列的取值很少，例如人事表的性別列，在查詢的成果中，成果集的數據行占了表中數據行的很年夜比例，即須要在表中搜刮的數據行的比例很年夜。增長索引，其實不能顯著加速檢索速度。
關於那些界說為text, image和bit數據類型的列不該該增長索引。這是由於，這些列的數據量要末相當年夜，要末取值很少。
當修正機能遠弘遠於檢索機能時，不該該創立索引。這是由於，修正機能和檢索機能是相互抵觸的。
假如表數據很少，好比每一個省按市做匯總的表，普通低於2000，且數據量根本沒有變更。此時增長索引無助於查詢機能，卻會極年夜的影響更新機能。
當增長索引時，會進步檢索機能，然則會下降修正機能。當削減索引時，會進步修正機能，下降檢索機能。是以，當對修正機能的請求遠弘遠於檢索機能時，不該該創立索引。
4.3. 結合索引
在特定查詢裡，結合索引的後果高於多個單一索引，由於當有多個索引可使用時，MySQL只能應用個中一個。
在查詢裡，同時用到了結合索引包括的前幾個列名，都邑應用到結合索引，不然將部門或不會用到。好比我們有一個firstname、 lastname、age列上的多列索引，我們稱這個索引為fname_lname_age。當搜刮前提是以下各類列的組應時，MySQL將應用 fname_lname_age索引：
firstname，lastname，age
firstname，lastname
firstname
從另外一方面懂得，它相當於我們創立了(firstname，lastname，age)、(firstname，lastname)和(firstname)這些列組合上的索引。
4.4. 索引長度
關於CHAR或許Varchar的列，索引可以依據數據的散布情形，用列的一部門介入創立索引。
create index idx_t_main on t_main(name(3));
這裡就是指定name的前三個字符介入索引，而不是全體
最年夜許可的長度為1000個字節，對已GBK編碼則是500個漢字
5. 特別字段
5.1. 冗余字段
就是用空間換取時光。假如年夜表查詢裡常常要join某個基本表，且這個數據根本不變，好比人的姓名，城市的名字等。一旦基本表產生更改，則須要更新一切觸及到的冗余表。
5.2. 朋分字段
假如常常湧現以某個字段的某個部分停止檢索和匯總(substring())，可以斟酌將這一部門自力出來。
好比統計姓名裡，每種姓氏的人數，可以斟酌完成就依照姓和名分離保留，而不是一個字段。
還有就是某些高低級構造的完成，也能夠斟酌將分歧的級別放在分歧的字段裡。
5.3. BLOB和CLOB
此類字段普通數據量很年夜，建議設計上數據庫可以只保留其內部銜接，而數據以其它方法保留，好比體系文件。
6. 特別
6.1. 表格朋分
假如一個表有很多的列，但日常平凡介入查詢和匯總的列卻其實不是許多，此時可以斟酌將表格拆分紅2個表，一個是經常使用的字段，另外一個是很罕用到的字段。
6.2. 應用非事務表類型
MySQL支撐多種表類型，個中InnoDB類型是支撐事物的，而MyISAM類型是不支撐的，但MyISAM速度更快。關於某些數據，好比地輿行政劃分，平易近族等弗成能介入事務的數據，可以斟酌用MyISAM類型的表格。
但InnoDB的表，將沒法用MyISAM表數據做外鍵束縛了。
MyISAM表介入的事務，其InnoDB表可以正常的提交和回滾，但不影響MyISAM表。
