MySQL篇—數據庫的設計和列類型選取真的很講究！

選擇更優的數據類型

1. 儘可能選擇存儲空間更小的數據類型

空間更小佔用的磁盤空間會更小，更加節省空間

2. 數據類型儘可能簡單

能夠選擇簡單的數據類型就不要選擇複雜的，例如能夠用INT存儲數據就不要用DOUBLE或者FLOAT存儲，這沒有任何意義

3. 儘可能不要使用NULL值列

由於NULL會給索引帶來額外的存儲空間、在SQL查詢中更難優化

整數類型

類型	佔用空間（BIT）
TINYINT	8
SMALLINT	16
MEDIUMINT	24
INT	32
BIGINT	64

通常會選擇BIGINT做爲主鍵列的列類型，注意：即便在建立列時指定數據長度，也沒法改變佔用空間。例如INT(11)和INT(20)都是佔用32位存儲空間，指定數據長度只可以在顯示結果的時候起做用。

在運算操做中，通常會使用BIGINT數據類型，即便在32位計算機中也如此。

實數類型

實數類型包括了小數部分，在MySQL中主要有三種數據類型：FLOAT、DOUBLE、DECIMAL

數據類型	佔用空間（Byte）
FLOAT	4
DOUBLE	8
DECIMAL	動態指定

FLOAT和DOUBLE都是採用近似浮點運算，有可能出現精度損失問題；DECIMAL是精確存儲數字的類型，在運算中能夠不損失精度，通常用於精確數值運算場景-例如財務數據；DECIMAL類型每9個數字佔用4個字節。

DECIMAL能夠動態指定數據長度，例如：DECIMAL(18, 9)表明保留小數點前9位、後9位，存儲空間爲9個字節，小數點佔1個字節。

注意：CPU自己不支持浮點數的精確運算，DECIMAL的精確運算在MySQL服務器中實現，而運算速度比CPU的浮點運算慢，即FLOAT和DOUBLE的運算比DECIMAL快

字符串類型

數據類型	特色
CHAR	定長、MySQL5.0開始去除結尾空格
VARCHAR	變長、MySQL5.0開始保留結尾空格、額外佔用1~2個字節標識數據長度

選用VARCHAR的標準：

1. 數據的長度差別較大
2. 不肯定數據的長度
3. 每一個字符佔用的字節數不一致，例如UTF-8編碼下的字符可能佔用1~2個字節

選用CHAR的標準：

1. 數據的長度較一致，例如長度相同的MD5散列碼值
2. 數據長度很短的列，例如存儲'Y'或'N'，由於VARCHAR須要額外1個字節存儲數據長度

VARCHAR類型在更新時可能由於數據長度變得比原來更長，磁盤沒有足夠的存儲空間存儲該值，致使頁分裂；而CHAR類型相對穩定，由於長度一致。

VARCHAR類型有可能致使內存碎片，它在存儲值時若是數據長度未滿，則會浪費一些存儲空間，因此定義VARCHAR的數據長度須要謹慎考慮，以避免產生大量內存碎片。例如VARCHAR(20)和VARCHAR(255)存儲最大長度爲15個字節的字符串，那麼VARCHAR(255)就很是奢侈了。

日期和時間類型

數據類型	特性
TIMESTAMP	與時區有關，日期範圍爲1970~2038年，佔用4個字節，默認爲NOT NULL
DATETIME	與時區無關，保存日期時間，格式YYYYMMHHMMSS，日期範圍1000-9999年，佔用8個字節

建議使用TIMESTAMP而不是DATETIME，由於在存儲空間上佔有優點，TIMESTAMP能夠利用FROM_UNIXTIME()轉換爲日期，UNIX_TIMESTAMP()轉換爲時間戳，也能夠在應用程序級別上進行二者的轉換輸出。

因爲TIMESTAMP默認是NOT NULL，若是在插入時沒有指定時間戳，會採用當前的時間戳存儲。

位數據類型

數據類型	特性
BIT	最大佔用64位，動態指定長度，保存二進制串
SET	一系列打包的位數據類型的集合，沒法使用索引

在開發中應儘可能少或者很是謹慎的使用BIT，緣由以下：

1. 在字符串上下文中，BIT查詢到的結果是ASCII碼對應的字符，而在數字上下文中，顯示的是ASCII碼自己的值

例如：

CREATE TABLE bittest(a bit(8));
INSERT INTO bittest (a) VALUES (b'00111001');
SELECT a, a + 0 FROM bittest;
複製代碼

a	a + 0
9	57

SET能夠用於存儲多個BIT的值，例如('dog', 'fish', 'chicken')，可是帶來的代價是修改表開銷很是大，因此有另一種更好的方式替代SET-利用整數的每一位表明不一樣的含義。

例如：使用TINYINT，佔用8位，'dog'採用最低位，'fish'採用次低位，'chicken'採用次次低位

含義	整數值
dog	1
fish	2
chicken	4
dog、chicken	5

這樣作的好處：

1. 若是要表示新的含義，不用頻繁地修改表
2. 能夠在應用程序級別上表示各個值的含義

相似的Linux操做文件的權限：

1. READ：4
2. WRITE：2
3. EXECUTE：1

那麼也可使用TINYINT標識某個用戶的執行權限

含義	整數值
READ、WRITE、EXECUTE	7
READ	4
READ、WRITE	6
EXECUTE	1
······	······

選擇標識列

一般有兩種選擇：整數類型、字符串類型

整數類型：

1. 最好採用AUTO_INCREMENT，這有利於提升索引查找的效率，由於相鄰的數據在磁盤上相隔不遠，大機率在同一個磁盤頁內；

字符串類型：

1. 因爲字符串類型是無序的，在索引分佈上不均勻，根據主鍵查找數據時效率很是低，若是使用字符串作主鍵，最好採用UUID()生成主鍵，由於在某種程度上UUID生成的字符串也是有序的，只不過程度很低
2. 插入時，查找插入的位置也要比整數類型效率低下，緣由也是由於索引分佈不均勻

範式和反範式的使用

先看看什麼是三範式：

1. 第一範式知足每一列都是不可再分的、最小的原子列
2. 第二範式知足非主屬性徹底依賴於主屬性
3. 第三範式知足全部非主屬性都直接依賴於主屬性，沒有傳遞依賴

數據庫三大範式實例

經典的「僱員-部門-領導」表：

EMPLOYEE_ID	EMPLOYEE	DEPARTMENT	HEAD
1	Jones	Accounting	Jones
2	Smith	Engineering	Smith
3	Brown	Accounting	Jones
4	Green	Engineering	Smith

該表存在以下問題：

1. 若是員工不存在，部門和領導的信息也無法顯示
2. 若是員工Jones和Brown的部門領導顯示不一致，就不知道哪一個是正確的了

因此上面的表結構符合第一範式，第一範式有可能出現的問題就是：刪除異常、修改異常

範式化

將上面的表「升級」，獲得的結果以下

「員工-部門」表：

EMPLOYEE_ID	EMPLOYEE	DEPARTMENT_ID
1	Jones	1
2	Smith	2
3	Brown	1
4	Green	2

「部門-領導」表：

DEPARTMENT_ID	DEPARTMENT	HEAD
1	Accounting	Jones
2	Engineering	Smith

解決了上面的兩個問題了：

1. 這裏的DEPARTMENT_ID做爲外鍵關聯列，只要DEPARTMENT或者HEAD做修改，都不會產生一致性問題
2. 即便刪除全部的EMPLOYEE也不會丟失部門信息

上面的表結構符合第二範式（實際上也知足第三範式），在不少狀況下符合第二範式已經很不錯了，範式化的缺點有：

1. 範式越高，查詢的代價越大，形成過多的表關聯，第三範式便是如此
2. 關聯查詢在一些狀況下使索引失效，全表掃描

範式化的優勢有：

1. 每張表的內存較小，數據操做更快
2. 更新操做更容易、代價更小
3. 不多出現冗餘數據，例如第一範式存在DEPARTMENT和HEAD冗餘

反範式化

"USER"用戶表：

USER_ID	USER_NAME	ACCOUNT_TYPE
1	Jhon	premiumv
2	Jack	guest
3	Sam	guest
4	Mike	premiumv

"MESSAGE"消息表：索引列（PUBLISHED）

MESSAGE_ID	MESSAGE_TEXT	PUBLISHED	USER_ID
1	HELLO, I AM JHON!	2020-01-01 12:00:00	1
2	HELLO, IT'S SAD TODAY!	2020-01-02 23:11:12	1
3	I AM SORRY TO HEAR THAT	2020-01-03 09:00:00	2
4	BYE BYE!	2020-01-03 10:00:00	3
5	I AM PREMIUMV!	2020-01-04 9:33:33	4

要查看付費用戶的最近的10條消息，能夠用關聯查詢：

SELECT MESSAGE_TEXT, USER_NAME
FROM USER
INNER JOIN MESSAGE
ON USER.USER_ID = MESSAGE.USER_ID
WHERE ACCOUNT_TYPE = 'preminmv'
ORDER BY PUBLISHED DESC
LIMIT 10;
複製代碼

可是這會掃描USER表中的全部用戶，判斷是否是付費用戶preminmv，效率極低，即便調換查詢順序也是同樣的道理，此時能夠在MESSAGE表中增長兩個冗餘字段ACCOUNT_TYPE和USER_NAME，創建索引(PUBLISHED, ACCOUNT_TYPE)，只須要查詢MESSAGE表，且能夠利用組合索引掃描，效率提升不少。

SELECT MESSAGE_TEXT, USER_NAME
FROM MESSAGE
WHERE ACCOUNT_TYPE='preminmv'
ORDER BY PUBLISHED DESC
LIMIT 10;
複製代碼

反範式化大部分都是經過添加冗餘字段達到目的，優勢是：

1. 避免關聯查詢，可使用組合索引提升查詢效率

缺點是：

1. 字段冗餘（這看起來很搞笑）

混用範式化和反範式化

徹底的範式化致使查詢的昂貴代價、徹底的反範式化致使插入異常和刪除異常，折中的辦法就是二者混用：

1. 若是在某個查詢中代價過大，加入冗餘字段能夠減輕查詢的代價（參考反範式化）
2. 若是存在插入異常和刪除異常，果斷須要範式化（參考範式化）