你應該知道的數據庫數據類型及其設計原則

MudOnTire 發布于2019-08-16 13:53 / 467人閱讀

摘要：整數類型整數類型有，分別使用位存儲空間。實數類型實數類型有，分別占用，字節。簡單數據類型的操作需要更少的周期。

1. 整數類型

整數類型有：tinyint、smallint、mediumint、int、bigint，分別使用 8、16、24、32、64 位存儲空間。它們可以存儲的值范圍從 -2 的 (n-1) 次方到 2 的 (n-1) 次方 -1，n 是存儲空間的位數。

整數有可選的 unsigned 屬性（無符號類型），表示不允許有負值，因此可以使正數上限提高一倍。

有符號和無符號類型使用相同的存儲空間，并具有相同的性能，因此可以根據實際情況選擇合適的類型。

2. 實數類型

實數類型有：FLOAT、DOUBLE ，分別占用 4，8 字節。

如果插入值的精度（即：數字總位數）高于實際定義的精度，系統會自動進行四舍五入處理，使值的精度達到要求。

其中 DECIMAL 也可以用來指定精度，并且它比 FLOAT 和 DOUBLE 更適合做精確計算。在本文就不做詳細介紹了，如果有人想了解的話可以給我留言，我下次再寫。

3. 字符串類型

字符串類型有：

VARCHAR

CHAR

BLOB

TEXT

由于 BLOB 和 TEXT 不常用且由于篇幅問題，就不展開描述了。本文主要對 VARCHAR 和 CHAR 進行介紹，它們的區別如下表：

對比內容	VARCHAR	CHAR
是否固定長度	否	是
存儲上限字節	65535	255
保存或檢索值時，是否刪除字符串末尾空格	否	是
超過設置的范圍后，字符串是否會被截斷	否	是

除了以上不同之外，VARCHAR 還需要額外使用 1 個或 2 個字節來記錄字符串長度。如果列的最大長度小于或等于 255 字節，則使用 1 個字節，否則使用 2 個字節。

由于 VARCHAR 是變長的，所以在 update 時，可能使行變得比原來更長，這就導致需要進行額外的工作。如果一個行占用的空間增加，并且在頁內沒有更多空間可以存儲，在這種情況下，不同存儲引擎的處理方式不一樣的。例如：MyISAM 會將行拆分為不同的片段存儲，InnoDB 則需要分裂頁來使行可以放進頁內。

在選擇使用場景上，重點要抓住 VARCHAR 是變長，CHAR 是定長的特點。

比如在這些情況更適合使用 VARCHAR：

字符串的最大長度比平均長度大很多；

字段更新次數少（所以碎片不是問題）；

使用了像 UTF-8 這樣復雜的字符集，每個字符都使用不同的字節數進行存儲。

而在這些情況則更適合使用 CHAR：

存儲很短的字符串（而 VARCHAR 還要多一個字節來記錄長度，本來打算節約存儲的現在反而得不償失）

定長的字符串（如 MD5、uuid）；

需要頻繁修改的字段。因為 VARCHAR 每次存儲都要有額外的計算，得到長度等工作；

這里拋出一個小問題：使用 VARCHAR(5) 和 VARCHAR(200) 來存儲 ‘hello’ 的空間開銷是一樣的。那么使用更短的列有什么好處呢？（思考幾秒鐘？）

答案：節約內存，因為更長的列會消耗更多的內存。MySQL 通常會分配固定大小的內存塊來保存內部值。尤其是使用內存臨時表進行排序或操作時會特別糟糕。在利用磁盤臨時進行排序時也同樣糟糕。

所以最好的策略是只分配真正需要的空間。

4. 日期和時間類型

下面表格是 TIMESTAMP 和 DATETIME 的一些對比：

對比內容	TIMESTAMP	DATETIME
占用字節	4	8
時間范圍	1970-01-01 08:00:01 ～ 2038-01-19 11:14:07	1000-01-01 00:00:00 ~ 9999-12-31 23:59:59
存儲的數據是否隨時區變化	是	否

如果在插入數據時，沒有指定第一個 TIMESTAMP 列的值，MySQL 則將這個列設置為當前時間，同時 TIMESTAMP 比 DATETIME 的空間效率更高。

最后，網上有很多討論，時間到底要使用 INT、TIMESTAMP、DATETIME 哪種類型更適合。我認為這沒有一個固定答案，具體可以參考文章：《選擇合適的 MySQL 日期時間類型來存儲你的時間》，我放在原文鏈接里面了。

5. 設計合理的數據類型

提供給大家 3 點設計原則：

更小的通常更好

簡單就好

盡量避免 NULL

下面對其詳細說明一下：

一般情況下，應該選擇可以正確存儲數據的最小數據類型，因為它們占用更少的磁盤、內存和 CPU 緩存，并且處理時需要的 CPU 周期也更少。

簡單數據類型的操作需要更少的 CPU 周期。例如，整型比字符操作代價更低，因為字符集和校對規則（排序規則）使字符比較比整型比較更復雜。

通常情況下，最好指定列為 NOT NULL，除非真的需要存儲 NULL 值。因為可為 NULL 的列會使索引、索引統計和值比較都更復雜。可為 NULL 的列會使用更多的存儲空間，在 MySQL 里也需要特殊處理。

當可為 NULL 的列被索引時，每個索引需要一個額外的字節，在 MyISAM 里甚至還可能導致固定大小的索引變成可變大小的索引。通常把可為 NULL 的列改為 NOT NULL 帶來的性能比較小，所以在優化時沒有必要先在現有表里修改這種情況。

參考：
《高性能 MySQL》

歡迎關注微信公眾號「不只Java」，后臺回復「電子書」，送說不定有你想要的呢

文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。

轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/72517.html

php設計模式

摘要：我們今天也來做一個萬能遙控器設計模式適配器模式將一個類的接口轉換成客戶希望的另外一個接口。今天要介紹的仍然是創建型設計模式的一種建造者模式。設計模式的理論知識固然重要，但計算機程序的思維邏輯 (54) - 剖析 Collections - 設計模式上節我們提到，類 Collections 中大概有兩類功能，第一類是對容器接口對象進行操作，第二類是返回一個容器接口對象，上節我們介紹了...

Dionysus_go 2019-06-28 14:37 評論0 收藏0
php設計模式

摘要：我們今天也來做一個萬能遙控器設計模式適配器模式將一個類的接口轉換成客戶希望的另外一個接口。今天要介紹的仍然是創建型設計模式的一種建造者模式。設計模式的理論知識固然重要，但計算機程序的思維邏輯 (54) - 剖析 Collections - 設計模式上節我們提到，類 Collections 中大概有兩類功能，第一類是對容器接口對象進行操作，第二類是返回一個容器接口對象，上節我們介紹了...

vspiders 2019-06-28 14:33 評論0 收藏0
第6章：可維護性軟件構建方法 6.1可維護性的度量和構造原則

摘要：設計方案的容易改變這就是所謂的軟件構建的可維護性，可擴展性和靈活性。這也可能表明類型或方法可能難以維護。基于源代碼中不同運算符和操作數的數量的合成度量。對修改的封閉這種模塊的源代碼是不可侵犯的。大綱軟件維護和演變可維護性度量模塊化設計和模塊化原則OO設計原則：SOLIDOO設計原則：GRASP總結軟件維護和演變什么是軟件維護？軟件工程中的軟件維護是交付后修改軟件產品以糾正故障...

chanjarster 2019-08-16 12:35 評論0 收藏0
后端好書閱讀與推薦（續）

摘要：續前文后端好書閱讀與推薦，幾十天過去了，又看了兩本好書還有以前看過的書，這里依然把它們總結歸納一下，加入一些自己的看法有用的鏈接和可能的延伸閱讀，并推薦給需要的同學。續前文后端好書閱讀與推薦 - Mageek`s Wonderland ，幾十天過去了，又看了兩本好書（還有以前看過的書），這里依然把它們總結歸納一下，加入一些自己的看法、有用的鏈接和可能的延伸閱讀，并推薦給需要的同學。...

劉福 2019-08-16 10:44 評論0 收藏0
后端好書閱讀與推薦（續）

摘要：續前文后端好書閱讀與推薦，幾十天過去了，又看了兩本好書還有以前看過的書，這里依然把它們總結歸納一下，加入一些自己的看法有用的鏈接和可能的延伸閱讀，并推薦給需要的同學。續前文后端好書閱讀與推薦 - Mageek`s Wonderland ，幾十天過去了，又看了兩本好書（還有以前看過的書），這里依然把它們總結歸納一下，加入一些自己的看法、有用的鏈接和可能的延伸閱讀，并推薦給需要的同學。...

OnlyLing 2019-08-21 16:22 評論0 收藏0