MySQL 數(shù)據(jù)表優(yōu)化設(shè)計(jì)(六):常見的數(shù)據(jù)表設(shè)計(jì)誤區(qū)整理

雖然會(huì)有一些常規(guī)意義上的數(shù)據(jù)表錯(cuò)誤設(shè)計(jì)和優(yōu)秀設(shè)計(jì)原則,但是同樣也會(huì)有 MySQL 特定的一些情況,這會(huì)導(dǎo)致我們犯一些 MySQL 特定的錯(cuò)誤。本篇討論常見的設(shè)計(jì)誤區(qū)。

誤區(qū)一:過多的數(shù)據(jù)列

MySQL 存儲(chǔ)引擎的 API 是按照行緩沖區(qū)方式從服務(wù)端和存儲(chǔ)引擎復(fù)制數(shù)據(jù)。服務(wù)端將緩沖區(qū)數(shù)據(jù)解碼成數(shù)據(jù)列。然而,將行緩沖區(qū)的格式轉(zhuǎn)換為數(shù)據(jù)行數(shù)據(jù)結(jié)構(gòu)的列可能會(huì)代價(jià)很高。MyISAM 固定使用與服務(wù)端匹配的行格式,因此無(wú)需轉(zhuǎn)換。然而,MyISAM 的可變行格式以及 InnoDB 的行格式總是需要進(jìn)行轉(zhuǎn)換。轉(zhuǎn)換的代價(jià)依賴于列的數(shù)量。如果當(dāng)數(shù)據(jù)表的列超過上百列的時(shí)候,會(huì)引起很高的 CPU 資源消耗——即便是使用到的列很少。曾經(jīng)看過一篇文章,指的是一個(gè)多語(yǔ)言的解決方案,直接簡(jiǎn)單粗暴地將系統(tǒng)支持的語(yǔ)言用對(duì)應(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)支持的語(yǔ)言越多,數(shù)據(jù)表的列越多,最終導(dǎo)致性能嚴(yán)重下降。如果你設(shè)計(jì)一個(gè)數(shù)據(jù)表的列數(shù)量超過100時(shí),就需要考慮你的設(shè)計(jì)是否合理了。
應(yīng)對(duì)方式:首先是考慮業(yè)務(wù)本身的設(shè)計(jì)是否合理,如果確實(shí)一個(gè)實(shí)體需要很多字段來(lái)描述,那么可以拆分?jǐn)?shù)據(jù)表,通過擴(kuò)展信息表來(lái)做。舉個(gè)例子,對(duì)于資訊類的數(shù)據(jù)表,因?yàn)閮?nèi)容一般占據(jù)的空間會(huì)比較大,但是在列表不會(huì)直接查看,就可以拆成資訊主表和資訊詳情表,主表存儲(chǔ)標(biāo)題、時(shí)間、摘要、縮略圖附件 id 等列表要查看的信息即可。而資訊詳情可以存儲(chǔ)資訊的內(nèi)容、來(lái)源、原文鏈接等信息。

誤區(qū)二:過多的聯(lián)合查詢

MySQL 一次聯(lián)合查詢最多只能61張表。而有些設(shè)計(jì)主張不做冗余字段設(shè)計(jì),這會(huì)導(dǎo)致復(fù)雜業(yè)務(wù)時(shí)需要連接多張表查詢。即便是聯(lián)合的表數(shù)量低于61個(gè),也會(huì)引起性能的下降,而且整個(gè) SQL 語(yǔ)句的維護(hù)將變得十分困難。作為一個(gè)設(shè)計(jì)的首要原則,就是如果想追求速度的話,一次查詢不要跨太多的數(shù)據(jù)表做聯(lián)合查詢,尤其面臨高并發(fā)場(chǎng)景的時(shí)候。
應(yīng)對(duì)方式:首先,對(duì)于確定不會(huì)改變的字段,可以考慮冗余字段的方式減少聯(lián)合查詢。例如,一家企業(yè)的所屬省份信息,就可以把省份代碼、省份名稱冗余了,而無(wú)需再通過省份代碼去查詢省份名稱。其次,確實(shí)需要查其他表的情況下,可以考慮使用分步查詢的方法,通過應(yīng)用程序完成數(shù)據(jù)的組裝,這種效率在數(shù)據(jù)表很多的時(shí)候會(huì)更高效,而且代碼也更好維護(hù)。
誤區(qū)三:萬(wàn)能的枚舉
例如下面這種表設(shè)計(jì):

CREATE TABLE t_countries (
  ...
  country ENUM('', '1', '2', ..., '45'),
  ...
);

這種方式本來(lái)可以通過一個(gè)以整數(shù)為 key的字典的查找表實(shí)現(xiàn)。如果是業(yè)務(wù)上增加了一個(gè)枚舉,意味著整個(gè)表都需要使用 ALTER TABLE更新。而如果是使用應(yīng)用代碼的查找表,只需要增加新的鍵值對(duì)就好了。
應(yīng)對(duì)方式:如果枚舉確定不會(huì)變動(dòng)(例如性別),那么沒問題。如果枚舉可能會(huì)增加,那么盡可能地通過應(yīng)用程序來(lái)實(shí)現(xiàn)。

誤區(qū)三:濫用 SET替代 ENUM

枚舉ENUM 類型是數(shù)據(jù)表列的值只能是值集合中的一個(gè),而 SET 類型是該列可以有一個(gè)或多個(gè)值。如果確定一個(gè)列只會(huì)有一個(gè)值,那么就應(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)對(duì)方式:從業(yè)務(wù)層面考慮列的值是不是可能有多個(gè),如果只有1個(gè)可選值那么就用 枚舉ENUM。

誤區(qū)四:生硬地避免NULL

很多文章都討論過盡可能地避免使用 NULL,對(duì)于大部分場(chǎng)景這是一個(gè)好的設(shè)計(jì),我們可以通過0,空字符串,約定的值等來(lái)表示空值。然而,不要因?yàn)檫@個(gè)而生硬套用,如果是這個(gè)值本身就是一個(gè)無(wú)意義的值的時(shí)候,那么使用 NULL 可能更合適。例如,如果要是有-1代表一個(gè)無(wú)意義的整數(shù),可能會(huì)導(dǎo)致代碼很復(fù)雜,甚至可能引起 bug。例如下面的例子:

CREATE TABLE t_person (
  birthday DATETIME NOT NULL DEFAULT '0000-00-00 00:00:00',
  ...,
);

將一個(gè) DATETIME 類型的默認(rèn)值設(shè)置為全部是0會(huì)很奇怪,假設(shè)我們要統(tǒng)計(jì)人員的年齡平均值的時(shí)候,會(huì)引起莫名其妙的問題,而這種場(chǎng)景使用 NULL 就不會(huì)納入到統(tǒng)計(jì)中來(lái)。可以通過設(shè)置 MySQL 的 SQL_MODE 參數(shù)禁止使用無(wú)意義的日期,避免出現(xiàn)這種情況。
應(yīng)對(duì)方式:設(shè)計(jì)表的時(shí)候可以盡量使用 NOT NULL 避免空值,但是不要過于生硬,對(duì)于有些字段使用默認(rèn)值無(wú)法表名意義或與實(shí)際不符時(shí),也是可以選擇使用 NULL 列的。只是,需要注意索引列不要使用NULL。而實(shí)際上,絕大部分索引列不太可能會(huì)是 NULL。

誤區(qū)五:使用整數(shù)替換時(shí)間戳

之前有講到過時(shí)間格式如何選擇的問題,實(shí)際上有些開發(fā)者會(huì)使用整數(shù)來(lái)存儲(chǔ)時(shí)間戳,他們的理由是這樣效率更高。從某種意義上來(lái)說,可能會(huì)提高一點(diǎn)效率,但是幫助不大,因?yàn)樵?MySQL 內(nèi)部DATETIME 和 TIMESTAMP 本身就是用整數(shù)存儲(chǔ)的。而如果使用整數(shù)存儲(chǔ)時(shí)間的話,意味著應(yīng)用程序中需要做時(shí)間轉(zhuǎn)換,或者是 SQL 語(yǔ)句要對(duì)指定的字段進(jìn)行時(shí)間轉(zhuǎn)換,帶來(lái)的收益可能得不償失。
應(yīng)對(duì)方式:盡可能地使用 DATETIME 存儲(chǔ)時(shí)間,如果需要存儲(chǔ)秒級(jí)精度一下的時(shí)間,那么可以考慮使用 BIGINT 來(lái)存儲(chǔ)。

誤區(qū)六:忘記字段的最大存儲(chǔ)范圍

在實(shí)際中設(shè)計(jì)表的時(shí)候會(huì)忘記數(shù)據(jù)類型的存儲(chǔ)范圍,比如使用 TINYINT(2)并不是只能存儲(chǔ)兩位整數(shù),實(shí)際TINYINT(2) 可以存儲(chǔ)的范圍是-128-127。 存儲(chǔ)超過255的整數(shù)。這種錯(cuò)誤在使用整數(shù)類型的時(shí)候很容易出現(xiàn)問題,在插入整數(shù)的時(shí)候,MySQL 不會(huì)檢查實(shí)際的整數(shù)位數(shù),而是按對(duì)應(yīng)存儲(chǔ)字節(jié)數(shù)的范圍存入,這種情況假設(shè)不注意會(huì)存入無(wú)意義的值。例如下面的 INSERT 操作會(huì)成功,而我們可能誤以為 TINYINT(2)只能存儲(chǔ)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)對(duì)方式:在應(yīng)用程序中做數(shù)據(jù)校驗(yàn)。

結(jié)語(yǔ):在實(shí)際設(shè)計(jì)數(shù)據(jù)表的過程中,除了需要考慮每個(gè)字段的數(shù)據(jù)類型之外,還需要考慮存儲(chǔ)空間大小。對(duì)于常用的一些字段,如時(shí)間、標(biāo)題、備注等,最好是內(nèi)部形成一定的規(guī)范,大家遵照規(guī)范執(zhí)行,并且增加校驗(yàn)?zāi)軌虮苊夂芏鄦栴}。

最后編輯于
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請(qǐng)聯(lián)系作者
  • 序言:七十年代末,一起剝皮案震驚了整個(gè)濱河市,隨后出現(xiàn)的幾起案子,更是在濱河造成了極大的恐慌,老刑警劉巖,帶你破解...
    沈念sama閱讀 227,488評(píng)論 6 531
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件,死亡現(xiàn)場(chǎng)離奇詭異,居然都是意外死亡,警方通過查閱死者的電腦和手機(jī),發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 98,034評(píng)論 3 414
  • 文/潘曉璐 我一進(jìn)店門,熙熙樓的掌柜王于貴愁眉苦臉地迎上來(lái),“玉大人,你說我怎么就攤上這事。” “怎么了?”我有些...
    開封第一講書人閱讀 175,327評(píng)論 0 373
  • 文/不壞的土叔 我叫張陵,是天一觀的道長(zhǎng)。 經(jīng)常有香客問我,道長(zhǎng),這世上最難降的妖魔是什么? 我笑而不...
    開封第一講書人閱讀 62,554評(píng)論 1 307
  • 正文 為了忘掉前任,我火速辦了婚禮,結(jié)果婚禮上,老公的妹妹穿的比我還像新娘。我一直安慰自己,他們只是感情好,可當(dāng)我...
    茶點(diǎn)故事閱讀 71,337評(píng)論 6 404
  • 文/花漫 我一把揭開白布。 她就那樣靜靜地躺著,像睡著了一般。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發(fā)上,一...
    開封第一講書人閱讀 54,883評(píng)論 1 321
  • 那天,我揣著相機(jī)與錄音,去河邊找鬼。 笑死,一個(gè)胖子當(dāng)著我的面吹牛,可吹牛的內(nèi)容都是我干的。 我是一名探鬼主播,決...
    沈念sama閱讀 42,975評(píng)論 3 439
  • 文/蒼蘭香墨 我猛地睜開眼,長(zhǎng)吁一口氣:“原來(lái)是場(chǎng)噩夢(mèng)啊……” “哼!你這毒婦竟也來(lái)了?” 一聲冷哼從身側(cè)響起,我...
    開封第一講書人閱讀 42,114評(píng)論 0 286
  • 序言:老撾萬(wàn)榮一對(duì)情侶失蹤,失蹤者是張志新(化名)和其女友劉穎,沒想到半個(gè)月后,有當(dāng)?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體,經(jīng)...
    沈念sama閱讀 48,625評(píng)論 1 332
  • 正文 獨(dú)居荒郊野嶺守林人離奇死亡,尸身上長(zhǎng)有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點(diǎn)故事閱讀 40,555評(píng)論 3 354
  • 正文 我和宋清朗相戀三年,在試婚紗的時(shí)候發(fā)現(xiàn)自己被綠了。 大學(xué)時(shí)的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片。...
    茶點(diǎn)故事閱讀 42,737評(píng)論 1 369
  • 序言:一個(gè)原本活蹦亂跳的男人離奇死亡,死狀恐怖,靈堂內(nèi)的尸體忽然破棺而出,到底是詐尸還是另有隱情,我是刑警寧澤,帶...
    沈念sama閱讀 38,244評(píng)論 5 355
  • 正文 年R本政府宣布,位于F島的核電站,受9級(jí)特大地震影響,放射性物質(zhì)發(fā)生泄漏。R本人自食惡果不足惜,卻給世界環(huán)境...
    茶點(diǎn)故事閱讀 43,973評(píng)論 3 345
  • 文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧,春花似錦、人聲如沸。這莊子的主人今日做“春日...
    開封第一講書人閱讀 34,362評(píng)論 0 25
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽(yáng)。三九已至,卻和暖如春,著一層夾襖步出監(jiān)牢的瞬間,已是汗流浹背。 一陣腳步聲響...
    開封第一講書人閱讀 35,615評(píng)論 1 280
  • 我被黑心中介騙來(lái)泰國(guó)打工, 沒想到剛下飛機(jī)就差點(diǎn)兒被人妖公主榨干…… 1. 我叫王不留,地道東北人。 一個(gè)月前我還...
    沈念sama閱讀 51,343評(píng)論 3 390
  • 正文 我出身青樓,卻偏偏與公主長(zhǎng)得像,于是被迫代替她去往敵國(guó)和親。 傳聞我的和親對(duì)象是個(gè)殘疾皇子,可洞房花燭夜當(dāng)晚...
    茶點(diǎn)故事閱讀 47,699評(píng)論 2 370