探讨關于MySQL數據表的schena缺陷設計踩坑

我們在創建數據庫時(shí)，基本都(dōu)有一些普遍的好(hǎo)與壞的設計原則，但有些隻有在MySQL中才會(huì)體現。這(zhè)裡(lǐ)會(huì)讨論一下MySQL的schema的問題，幫助我們避免這(zhè)樣(yàng)錯誤。

1、太多的列

有些人使用非常寬的表（數千字段），然而隻使用一小部分列，這(zhè)時(shí)的轉換代價就(jiù)很高。由于MySQL的存儲引擎API工作時(shí)需要在服務器層和數據層之間拷貝數據，然後(hòu)在服務器層將(jiāng)緩存的内容解碼成(chéng)各個列。

我們應該經(jīng)曆的減少不必要的字段，比如一些預留字段。如果需要新的字段，我們可以新增就(jiù)可以，不必刻意的去預留。

2、太多的關聯

實體-屬性-值（EAV）設計模式是一個糟糕的模式，尤其實在MySQL下不能(néng)靠譜的工作。MySQL限制每個關聯操作最多隻有61張表，但實際上在少于61張表下操作查詢代價也是MySQL的問題。一些粗略的測試

得到，單查詢最好(hǎo)在12張表以内做關聯。

3、全能(néng)的枚舉

枚舉類型可以解決一些性能(néng)和錯誤的操作，但如果過(guò)度的是呀枚舉會(huì)讓schema的設計非常亂。所以我們應該經(jīng)理的避免大量的使用枚舉，對(duì)一些關鍵字段使用枚舉就(jiù)可以。

4、避免全部NULL

MySQL中我們應該盡量的避免NULL（空）的存儲，就(jiù)算存儲實際上存儲一個“空值”，我們也盡量的避免存儲NULL，可以用其他的代替如 “0”，或者其他的特殊符号。

但我們也不必走向(xiàng)極端，對(duì)于一些未知值時(shí)也不要害怕的使用NULL。