您好,登錄后才能下訂單哦!
這篇文章將為大家詳細(xì)講解有關(guān)MySQL中常見的數(shù)據(jù)表設(shè)計(jì)誤區(qū)有哪些,小編覺得挺實(shí)用的,因此分享給大家做個參考,希望大家閱讀完這篇文章后可以有所收獲。
MySQL 存儲引擎的 API 是按照行緩沖區(qū)方式從服務(wù)端和存儲引擎復(fù)制數(shù)據(jù)。服務(wù)端將緩沖區(qū)數(shù)據(jù)解碼成數(shù)據(jù)列。然而,將行緩沖區(qū)的格式轉(zhuǎn)換為數(shù)據(jù)行數(shù)據(jù)結(jié)構(gòu)的列可能會代價很高。MyISAM 固定使用與服務(wù)端匹配的行格式,因此無需轉(zhuǎn)換。然而,MyISAM 的可變行格式以及 InnoDB 的行格式總是需要進(jìn)行轉(zhuǎn)換。轉(zhuǎn)換的代價依賴于列的數(shù)量。如果當(dāng)數(shù)據(jù)表的列超過上百列的時候,會引起很高的 CPU 資源消耗——即便是使用到的列很少。曾經(jīng)看過一篇文章,指的是一個多語言的解決方案,直接簡單粗暴地將系統(tǒng)支持的語言用對應(yīng)的列表示,例如:
CREATE TABLE t_multi_language_news ( id INT PRIMARY KEY, title_cn VARCHAR(32), title_en VARCHAR(32), title_it VARCHAR(32), ... content_cn VARVHAR(256), content_en VARCHAR(256), conntent_it VARCHAR(256), );
這種方式隨著系統(tǒng)支持的語言越多,數(shù)據(jù)表的列越多,最終導(dǎo)致性能嚴(yán)重下降。如果你設(shè)計(jì)一個數(shù)據(jù)表的列數(shù)量超過100時,就需要考慮你的設(shè)計(jì)是否合理了。 **應(yīng)對方式:**首先是考慮業(yè)務(wù)本身的設(shè)計(jì)是否合理,如果確實(shí)一個實(shí)體需要很多字段來描述,那么可以拆分?jǐn)?shù)據(jù)表,通過擴(kuò)展信息表來做。舉個例子,對于資訊類的數(shù)據(jù)表,因?yàn)閮?nèi)容一般占據(jù)的空間會比較大,但是在列表不會直接查看,就可以拆成資訊主表和資訊詳情表,主表存儲標(biāo)題、時間、摘要、縮略圖附件 id 等列表要查看的信息即可。而資訊詳情可以存儲資訊的內(nèi)容、來源、原文鏈接等信息。
MySQL 一次聯(lián)合查詢最多只能61張表。而有些設(shè)計(jì)主張不做冗余字段設(shè)計(jì),這會導(dǎo)致復(fù)雜業(yè)務(wù)時需要連接多張表查詢。即便是聯(lián)合的表數(shù)量低于61個,也會引起性能的下降,而且整個 SQL 語句的維護(hù)將變得十分困難。作為一個設(shè)計(jì)的首要原則,就是如果想追求速度的話,一次查詢不要跨太多的數(shù)據(jù)表做聯(lián)合查詢,尤其面臨高并發(fā)場景的時候。 **應(yīng)對方式:**首先,對于確定不會改變的字段,可以考慮冗余字段的方式減少聯(lián)合查詢。例如,一家企業(yè)的所屬省份信息,就可以把省份代碼、省份名稱冗余了,而無需再通過省份代碼去查詢省份名稱。其次,確實(shí)需要查其他表的情況下,可以考慮使用分步查詢的方法,通過應(yīng)用程序完成數(shù)據(jù)的組裝,這種效率在數(shù)據(jù)表很多的時候會更高效,而且代碼也更好維護(hù)。 誤區(qū)三:萬能的枚舉 例如下面這種表設(shè)計(jì):
CREATE TABLE t_countries ( ... country ENUM('', '1', '2', ..., '45'), ... );
這種方式本來可以通過一個以整數(shù)為 key的字典的查找表實(shí)現(xiàn)。如果是業(yè)務(wù)上增加了一個枚舉,意味著整個表都需要使用 ALTER TABLE更新。而如果是使用應(yīng)用代碼的查找表,只需要增加新的鍵值對就好了。 **應(yīng)對方式:**如果枚舉確定不會變動(例如性別),那么沒問題。如果枚舉可能會增加,那么盡可能地通過應(yīng)用程序來實(shí)現(xiàn)。
枚舉ENUM 類型是數(shù)據(jù)表列的值只能是值集合中的一個,而 SET 類型是該列可以有一個或多個值。如果確定一個列只會有一個值,那么就應(yīng)該優(yōu)先使用枚舉,而不是集合。例如下面的例子就是典型的濫用:
CREATE TABLE t_payment_way ( ... is_default SET('Y', 'N') NOT NULL DEFAULT 'N', ... );
很顯然,is_default 要么是 Y,要么是 N,因此這里應(yīng)該使用 ENUM。 **應(yīng)對方式:**從業(yè)務(wù)層面考慮列的值是不是可能有多個,如果只有1個可選值那么就用 枚舉ENUM。
很多文章都討論過盡可能地避免使用 NULL,對于大部分場景這是一個好的設(shè)計(jì),我們可以通過0,空字符串,約定的值等來表示空值。然而,不要因?yàn)檫@個而生硬套用,如果是這個值本身就是一個無意義的值的時候,那么使用 NULL 可能更合適。例如,如果要是有-1代表一個無意義的整數(shù),可能會導(dǎo)致代碼很復(fù)雜,甚至可能引起 bug。例如下面的例子:
CREATE TABLE t_person ( birthday DATETIME NOT NULL DEFAULT '0000-00-00 00:00:00', ..., );
將一個 DATETIME 類型的默認(rèn)值設(shè)置為全部是0會很奇怪,假設(shè)我們要統(tǒng)計(jì)人員的年齡平均值的時候,會引起莫名其妙的問題,而這種場景使用 NULL 就不會納入到統(tǒng)計(jì)中來??梢酝ㄟ^設(shè)置 MySQL 的 SQL_MODE 參數(shù)禁止使用無意義的日期,避免出現(xiàn)這種情況。 **應(yīng)對方式:**設(shè)計(jì)表的時候可以盡量使用 NOT NULL 避免空值,但是不要過于生硬,對于有些字段使用默認(rèn)值無法表名意義或與實(shí)際不符時,也是可以選擇使用 NULL 列的。只是,需要注意索引列不要使用NULL。而實(shí)際上,絕大部分索引列不太可能會是 NULL。
之前有講到過時間格式如何選擇的問題,實(shí)際上有些開發(fā)者會使用整數(shù)來存儲時間戳,他們的理由是這樣效率更高。從某種意義上來說,可能會提高一點(diǎn)效率,但是幫助不大,因?yàn)樵?MySQL 內(nèi)部DATETIME 和 TIMESTAMP 本身就是用整數(shù)存儲的。而如果使用整數(shù)存儲時間的話,意味著應(yīng)用程序中需要做時間轉(zhuǎn)換,或者是 SQL 語句要對指定的字段進(jìn)行時間轉(zhuǎn)換,帶來的收益可能得不償失。 **應(yīng)對方式:**盡可能地使用 DATETIME 存儲時間,如果需要存儲秒級精度一下的時間,那么可以考慮使用 BIGINT 來存儲。
在實(shí)際中設(shè)計(jì)表的時候會忘記數(shù)據(jù)類型的存儲范圍,比如使用 TINYINT(2)并不是只能存儲兩位整數(shù),實(shí)際TINYINT(2) 可以存儲的范圍是-128-127。 存儲超過255的整數(shù)。這種錯誤在使用整數(shù)類型的時候很容易出現(xiàn)問題,在插入整數(shù)的時候,MySQL 不會檢查實(shí)際的整數(shù)位數(shù),而是按對應(yīng)存儲字節(jié)數(shù)的范圍存入,這種情況假設(shè)不注意會存入無意義的值。例如下面的 INSERT 操作會成功,而我們可能誤以為 TINYINT(2)只能存儲2位整數(shù):
CREATE TABLE t_int_test ( id INT PRIMARY KEY, number TINYINT(2) ); INSERT INTO t_int_test (id, number) VALUES (3,123);
應(yīng)對方式:在應(yīng)用程序中做數(shù)據(jù)校驗(yàn)。
關(guān)于“MySQL中常見的數(shù)據(jù)表設(shè)計(jì)誤區(qū)有哪些”這篇文章就分享到這里了,希望以上內(nèi)容可以對大家有一定的幫助,使各位可以學(xué)到更多知識,如果覺得文章不錯,請把它分享出去讓更多的人看到。
免責(zé)聲明:本站發(fā)布的內(nèi)容(圖片、視頻和文字)以原創(chuàng)、轉(zhuǎn)載和分享為主,文章觀點(diǎn)不代表本網(wǎng)站立場,如果涉及侵權(quán)請聯(lián)系站長郵箱:is@yisu.com進(jìn)行舉報(bào),并提供相關(guān)證據(jù),一經(jīng)查實(shí),將立刻刪除涉嫌侵權(quán)內(nèi)容。