高效能的MySQL(4)資料型別的優化

2021-09-03 09:28:24 字數 2276 閱讀 1523

一、基本原則

1、更小的通常更好

更小的資料型別通常更快,因為占用更少的磁碟、記憶體和cpu快取,並且處理時需要的cpu週期也更少。

但是要確保沒有低估需要儲存的值的範圍,因為在schema中的多個地方增加資料型別的範圍是個非常耗時的操作。

2、簡單就好

例如,整數比字串操作代價更低,應該用內建型別而不是字串來儲存時間和日期,用整型儲存ip。

3、盡量避免null

可為null的列使用更多的儲存空間,需要特殊的處理。特別是可為null的列被索引時,每個索引需要額外的位元組,在myisam引擎裡甚至還可能導致固定大小的索引,所以計畫建立索引的列,要避免使用null。

二、資料型別

1、整數型別

tinyint、smallint、mediuint、int、bigint,分別使用8、16、24、32、64位儲存空間。範圍從-2(n-1)次方到2(n-1)次方-1。

指定範圍,只是一種顯示,對儲存和計算來說int(1)和int(20)是一樣的。

2、實數型別

float和double支援使用標準的浮點運算進行近似計算。

decimal型別用於儲存精確的小數

浮點型別在儲存同樣的範圍的值是,通常比decimal使用的空間更少。因為額外的空間和計算開銷所以應該只在對小數進行精確計算時才使用,也可以考慮使用bigint代替decimal,將小數的位數乘以相應的倍數即可。

3、字串型別

varchar型別用於儲存可變長字串,但是需要1-2個額外位元組記錄字串的長度。由於行是變長的,在update時不同的引擎需要不同的額外處理工作。同時儲存和檢索時會保留末尾空格。

char型別是定長的。儲存時會刪除末尾的空格。

對於字串最大長度比平均長度大很多,列的更新很少,適合varchar。對於經常更新的資料,char更好,因為不容易產生碎片。

4、blob和text型別

都是為儲存大的資料而設計的字串型別,分別採用二進位制和字元方式儲存,blob沒有排序規則和字符集。

mysql對blob和text列進行排序和其他型別是不同的,它只針對每個列的最前max_sort_length位元組排序,或者使用order by substring(column,length).

如果查詢使用了blob和text列並且需要使用隱式臨時表,將不得不用到myiasm磁碟臨時表,這是很大的系統開銷。如果無法避免,有乙個技巧是在所有使用到blob欄位的地方使用substring(column,length)將列值轉換為字串,這樣就可以使用記憶體臨時表了。但是要確保擷取的字串足夠短,不會使臨時表的大小超過max_heap_table_size和tmp_table_size,如果超過還是會使用磁碟臨時表的。

如果explain的extra列包含「using temporary」,則說明用到了隱式臨時表

5、enum型別

把一些不重複字串儲存成乙個預定義的集合,非常節省空間。mysql在內部會將每乙個值在列表中的位置儲存為整數,並且在表的.frm檔案中儲存「數字-字串」的對映關係的查詢表。只有在進行查詢時才會轉化為字串。

所以要盡量避免使用數字作為列舉值來儲存。

另外乙個要注意的是列舉欄位是按照內部儲存的整數來排序的,而不是字串。

所以盡量按照需要的順序來定義列舉列,也可以使用field()函式指定排序,但會導致無法利用索引消除排序。

列舉型別有另外乙個好處。根據show table status命令結果看data_length列的值,可以讓表的大小縮小1/3,同樣,轉換後主鍵也只有原來的一半了。

6、日期和時間型別

datetime:儲存從2023年到2023年,精度為秒,把日期和時間封裝到整數中,與時區無關,使用8個位元組儲存空間。

timestamp:儲存從1970到2023年的時間戳,可以使用unix_timestamp()和from_unixtime()來相互轉換。

除了特殊行為之外,通常也應該盡量使用timestamp,因為空間效率更高。

7、bit型別

儲存乙個或多個true/false值,最大64位。

mysql把bit當作字串型別而不是數字型別。當檢索bit(1)時,結果是包含二進位制0或1的字串,而不是ascii碼的0或1,然而,在數字場景中檢索時,結果是位字串轉換成的數字。

所以不建議使用bit型別。

8、set型別

儲存多個true/false值,修改列定義代價較高,需要alter table,而且無法使用索引。

可以使用整數列來進行按位操作,但是邏輯上的查詢語句就會很難些,因人而異選擇吧。

使用set

使用tinyint

標識列或者可能做外來鍵的列,最好使用整型型別。

《高效能mysql》二schema與資料型別優化

1 更小的通常更好 一般情況下,應該盡量使用可以正確儲存資料的最小資料型別。更小的資料型別通常更快,因為他們占用更少的磁碟 記憶體和cpu快取,並且處理時需要的cpu週期也更少。2 簡單就好 簡單資料型別的操作通常需要更少的cpu週期。3 盡量避免null 通常情況下最好指定列為not null,除...

高效能MySQL(三) Schema與資料型別優化

mysql schema設計中的問題 mysql支援的資料型別非常多,選擇正確的資料型別對於獲得高效能至關重要。下面幾個簡單的原則有助於做出更好的選擇 更小的通常更好 簡單就好 避免null 本篇預設儲存引擎是innodb 有兩種型別的數字 整數和實數。如果儲存整數,可以使用這幾種整數型別 tiny...

Schema與資料型別優化 高效能MySQL

關於資料型別選擇的一些記錄 tinyint 8 smallint 16 mediumint 24 int 32 bigint 64 可選屬性 unsigned。mysql可以為整型指定寬度,如int 11 但大多數時候沒有意義,只是規定了一些互動工具用來顯示字元的個數。從mysql4.1開始,每個字...