Mysql 表結構優化

2021-10-02 16:50:45 字數 1302 閱讀 3714

一、資料型別的選擇

簡單規則:

1、字元長度設定更小更好;

2、型別越簡單越好,越簡單使用的cpu越少;比如儲存時間字段採用varchar型別與datatime型別對比;

3、盡量避免使用null;因為可為null的列使得索引、索引統計和值比較都更加複雜;

實際細節:

1、整型:tinyint,smallint,mediumint,int,bigint分別使用8,16,24,32,64位儲存空

2、字元與字串型別:

(1)、char長度固定,最大長度255個位元組,適合儲存長度確定的資料,比如:手機號碼;

(2)、varchar可變長度,最大可儲存65535個位元組,適合用在長度可變的屬性,比如:名稱;

(3)、text不設長度。

3、日期型別:datetime和timestamp,其中timestamp採用的是int儲存,計算操作比較方便;

4、列舉型別:用來儲存常量,在mysql在內部會將每個值在列表中的位置儲存為整數,並且在表的.frm檔案中儲存「數            字-字串」對映關係的查詢表

二、主鍵的選擇     

**主鍵:與業務無關

自然主鍵:事務的唯一屬性

推薦使用**主鍵,避免高耦合性

三、儲存引擎的選擇         

功能                 mylsam    memory    innodb    archive

儲存限制          256tb       ram            64tb       none

支援事務          no             no                yes         no

支援全文索引   yes           no                 no          no

支援樹索引       yes           yes               yes         no

支援雜湊索引    no           yes               no          no

支援資料快取    no           n/a               yes         no

支援外來鍵           no           no                yes         no

四、資料冗餘

在某些情況下,為了提高效能,我們必須在時間與空間進行取捨。在mysql中,join僅僅只是為了取得某個小字段的值,而join到的記錄又大,會造成大量不必要的 io,顧可以對關聯較多的字段資料實現多表冗餘。

MySQL優化 表結構

資料型別 簡單的原則 1 更小的通常最好 why 更小的資料型別會占用更小的磁碟,記憶體和cpu快取,會產生更小的索引,處理時cpu週期更少。2 簡單就好 整數好於字串。why 整型比字元操作代價更低,因為字符集的排序規則使字元比較比整型比較更複雜。3 盡量避免null值 如何儲存null值,索引如...

MySQL優化四(優化表結構)

昨晚吃吃喝喝的太多,熬夜到凌晨二點。今天頭髮雜亂,臉龐憔悴,像是吸毒了。下午去買衣服,肚子一看大了不少。奈何女朋友還沒有乙個,就已經發福了。管不住口,邁不開腿。一 優化表結構 1.盡量將表字段定義為not null約束,這時由於在mysql中含有空值的列很難進行查詢優化,null值會使索引以及索引的...

MySQL效能優化之表結構優化

第一正規化 屬性 字段 的原子性約束,要求屬性具有原子性,不可再分割 第二正規化 記錄的惟一性約束,要求記錄有惟一標識,每條記錄需要有乙個屬性來做為實體的唯一標識。第三正規化 屬性 字段 冗餘性的約束,即任何字段不能由其他字段派生出來。外來鍵解決設計原則 在資料冗餘和處理速度之間找到合適的平衡點 資...