mysql中ROW_FORMAT的選擇問題
文章中看到這樣一句話,引起了我的深思,然后去研究了一下 ROW_FORMAT
CHAR 與VARCHAR 之間的特點與選擇
CHAR和VARCHAR的區(qū)別如下:
1)、CHAR是固定長度字符, VARCHAR是可變長度字符;
2)、CHAR會自動刪除插入數(shù)據(jù)的尾部空格, VARCHAR不會刪除尾部空格。
CHAR是固定長度,所以它的處理速度比VARCHAR的速度要快,但是它的缺點就是浪費存儲空間。所以對存儲不大,但在速度上有要求的可以使用CHAR類型,反之可以使用VARCHAR類型來實現(xiàn)。
存儲引擎對于選擇CHAR和VARCHAR的影響
對于MyISAM存儲引擎:最好使用固定長度的數(shù)據(jù)列代替可變長度的數(shù)據(jù)列。這樣可以使整個表靜態(tài)化,從而使數(shù)據(jù)檢索更快,用空間換時間。
對于InnoDB存儲引擎:使用可變長度的數(shù)據(jù)列,因為InnoDB數(shù)據(jù)表的存儲格式不分固定長度和可變長度,因此使用CHAR不一定比使用VARCHAR更好,但由于VARCHAR是按照實際的長度存儲,比較節(jié)省空間,所以對磁盤I/O和數(shù)據(jù)存儲總量比較好。
在MySQL中,所謂Row_Format行格式是指數(shù)據(jù)記錄(或者稱之為行)在磁盤中的物理存儲方式。
MyISAM行存儲
MyISAM有3種行存儲格式:fixed/dynamic/compressed
1、fixed:為默認格式,只有當表不包含變長字段(varchar/varbinary/blob/text)時使用,該每行都是固定的,所以很容易獲取行在頁上的具體位置,存取效率比較高,但是占用磁盤空間較多
InnoDB行存儲
Innodb plugin新引入Barracuda,其包含compressed/dynamic兩種行格式,而之前的compact/redundant統(tǒng)屬于antelope;
目前可選值為Antelope和Barracuda,低版本默認為Antelope,高版本默認為Barracuda。
1. Antelope: 它支持兩種行格式:COMPACT 和 REDUNDANT。MySQL5.6的默認文件格式。可以與早期的版本保持最大的兼容性。不支持 Barracuda 文件格式。
2. Barracuda: 新的文件格式。它支持InnoDB的所有行格式,包括新的行格式:COMPRESSED 和 DYNAMIC。
在 msyql 5.7.9 及以后版本,默認行格式由innodb_default_row_format變量決定,它的默認值是DYNAMIC,也可以在 create table 的時候指定ROW_FORMAT=DYNAMIC。用戶可以通過命令 SHOW TABLE STATUS LIKE'table_name' 來查看當前表使用的行格式,其中 row_format 列表示當前所使用的行記錄結(jié)構(gòu)類型。
如果要修改現(xiàn)有表的行模式為compressed或dynamic,必須先將文件格式設(shè)置成Barracuda:set global innodb_file_format=Barracuda;,再用ALTER TABLE tablename ROW_FORMAT=COMPRESSED;去修改才能生效。
InnoDB存儲引擎Compact、Redundant、Dynamic、Compressed主要區(qū)別
1)、compact、Dynamic、Compressed 行格式下,字段為NULL值是不會在記錄的數(shù)據(jù)內(nèi)容中占用存儲空間,冗余存儲的;
2)、redundant行格式下,如果值為NULL的字段類型為變長數(shù)據(jù)類型,不會在記錄的數(shù)據(jù)內(nèi)容中占用任何空間來進行存儲的,
如果值為NULL的字段類型為定長數(shù)據(jù)類型,其使用0x00來填充該字段所需占用的空間。
例如char(10)類型的字段,在ascii、utf8字符集中其Maxlen值分別為1、3。即該字段在數(shù)據(jù)內(nèi)容部分會分別占用的10、30個字節(jié)。故當該字段為NULL值時,會使用0x00來填充這10、30個字節(jié)的位置。
行溢出
compact、redundant行格式中,如果該記錄某字段中數(shù)據(jù)量過多時,則在該記錄的數(shù)據(jù)內(nèi)容的相應(yīng)字段處只存儲該字段值前768個字節(jié)的數(shù)據(jù)和一個指向存儲剩余數(shù)據(jù)的其他頁(即所謂的溢出頁)的地址,該地址通常占用20個字節(jié)。
Dynamic、Compressed行格式中,會把記錄中數(shù)據(jù)量過大的字段值全部存儲到溢出頁中,而不會在該記錄的數(shù)據(jù)內(nèi)容的相應(yīng)字段處存儲該字段值前768個字節(jié)的數(shù)據(jù)了。
而compressed相比較dynamic行格式來說,前者會使用壓縮算法對所有頁面(自然也包括溢出頁)進行壓縮以減少存儲占用。
遇到過這樣一個問題,原因是InnoDB不支持ROW_FORMAT為FIXED。
mysql> create table tmp11(id varchar(10)) ROW_FORMAT=FIXED; ERROR 1031 (HY000): Table storage engine for 'tmp11' doesn't have this option mysql> show variables like 'default_storage_engine'; +------------------------+--------+ | Variable_name | Value | +------------------------+--------+ | default_storage_engine | InnoDB | +------------------------+--------+ 1 row in set (0.00 sec)
總結(jié)
以上為個人經(jīng)驗,希望能給大家一個參考,也希望大家多多支持腳本之家。
相關(guān)文章
mysql創(chuàng)建用戶并賦予用戶權(quán)限詳細操作教程
這篇文章主要給大家介紹了關(guān)于mysql創(chuàng)建用戶并賦予用戶權(quán)限詳細操作的相關(guān)資料,文中通過示例代碼介紹的非常詳細,對大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價值,需要的朋友們下面隨著小編來一起學(xué)習(xí)學(xué)習(xí)吧2020-12-12MySQL表數(shù)據(jù)文件損壞導(dǎo)致數(shù)據(jù)庫無法啟動的原因與解決方案
在日常的數(shù)據(jù)庫管理中,遇到MySQL表數(shù)據(jù)文件損壞的情況并不罕見,這種情況下,MySQL數(shù)據(jù)庫可能會無法正常啟動,給業(yè)務(wù)運行帶來嚴重影響,本文將探討如何診斷和解決MySQL表數(shù)據(jù)文件損壞導(dǎo)致的數(shù)據(jù)庫無法啟動問題,需要的朋友可以參考下2025-03-03mysql按天/小時/半小時/N分鐘/分鐘進行數(shù)據(jù)分組統(tǒng)計功能
我們在做項目或者數(shù)據(jù)分析時,經(jīng)常遇到這樣的需求:統(tǒng)計不同時間粒度下的數(shù)據(jù)分布情況,例如,每一天中每個小時網(wǎng)站的訪問量,某路口每半個小時通過的車輛數(shù)量等,下面給大家分享mysql按天/小時/半小時/N分鐘/分鐘進行數(shù)據(jù)分組統(tǒng)計功能,感興趣的朋友跟隨小編一起看看吧2024-04-04