昨晚吃吃喝喝的太多,熬夜到凌晨二點。今天頭髮雜亂,臉龐憔悴,像是吸毒了。下午去買衣服,肚子一看大了不少。奈何女朋友還沒有乙個,就已經發福了。管不住口,邁不開腿。一、優化表結構
1.盡量將表字段定義為not null約束,這時由於在mysql中含有空值的列很難進行查詢優化,null值會使索引以及索引的統計資訊變得很複雜,可以使用0或者空字串來代替。
2.可以使用enum、set 等符合資料型別。對於只包含特定型別的字段。不過在工作過程中一般就使用tinyint 來表示了。
3.數值型字段的比較比字串的比較效率高得多,字段型別盡量使用最小、最簡單的資料型別。ip位址可以使用int型別。
二、表拆分
1、垂直拆分
垂直拆分按照字段進行拆分,其實就是把組成一行的多個列分開放到不同的表中,這些表具有不同的結構,拆分後的表具有更少的列,例如使用者表中的一些字段可能經常訪問,可以把這些字段放進一張表裡。另外一些不經常使用的資訊就可以放進另外一張表裡。插入的時候使用事務,也可以保證兩表的資料一致。缺點也很明顯,由於拆分出來的兩張表存在1:1的關係,需要使用冗餘字段,而且需要join操作,我們在使用的時候可以分別取兩次,這樣的來說既可以避免join操作,又可以提高效率。
2、水平拆分
水平拆分按照行進行拆分,常見的就是分庫分表。以使用者表為例,可以取使用者id,然後使用php的十進位制轉換16進製制的方法dechex
,擷取其中的第乙個字元,將使用者均勻的分配進這 0-9 、a-f 這16個表中。查詢的時候也按照這種規則,又快又方便。當然類似的規則很多,也可以使用求餘法,按照餘數將資料分發進不同的表中。有些表業務關聯比較強,那麼可以使用按時間劃分的。以我公司的某業務為例,每天都要新建一張表。這種業務型別就是需要高速插入,但是對於查詢的效率不太關心。表越大,插入資料所需要索引維護的時間也就越長。
三、分割槽
分割槽這個概念,我第一次在實踐中看到是在去年,資料中心的表按照時間乙個月分成乙個區。我從這些表中讀取資料,然後繼續做後續的業務處理。一般來說在主業務中很少使用這種分割槽概念,使用分割槽是大資料處理後的產物。比如系統使用者的註冊推廣等等,會產生海量的日誌,當然也可以按照時間去建立多張表,但在實際操作中,就發生過一次運維人員忘記切換表,導致資料報錯的緊急事件。可見分割槽適用於日誌記錄,查詢少,一般用於後台的資料包表分析。對於這些資料彙總需求,需要很多日誌表去做資料聚合,我們能夠容忍1s到2s的延遲,只要資料準確能夠滿足需求就可以。
mysql主要支援4種模式的分割槽:range分割槽、list預定義列表分割槽,hash 分割槽,key鍵值分割槽。後幾種沒有看到資料中心的同事用過,可能是操作不方便,應用不廣泛,所以就暫且不講了。
-- 建立表
create table testpar
( f_userid int unsigned not null default 0,
f_date datetime
)engine=innodb,charset=utf8;
-- 分割槽
alter table testpar partition by range columns(f_date) (
partition p0 values less than ('2017-01-31'),
partition p2 values less than ('2017-02-20')
);-- 檢視表結構
mysql> show create table testpar\g
*************************** 1. row ***************************
table: testpar
create table: create table `testpar` (
`f_userid` int(10) unsigned not null default '0',
`f_date` datetime default null
) engine=innodb default charset=utf8
/*!50500 partition by range columns(f_date)
(partition p0 values less than ('2017-01-31') engine = innodb,
partition p2 values less than ('2017-02-20') engine = innodb) */
1 row in set (0.00 sec)
MySQL優化 表結構
資料型別 簡單的原則 1 更小的通常最好 why 更小的資料型別會占用更小的磁碟,記憶體和cpu快取,會產生更小的索引,處理時cpu週期更少。2 簡單就好 整數好於字串。why 整型比字元操作代價更低,因為字符集的排序規則使字元比較比整型比較更複雜。3 盡量避免null值 如何儲存null值,索引如...
Mysql 表結構優化
一 資料型別的選擇 簡單規則 1 字元長度設定更小更好 2 型別越簡單越好,越簡單使用的cpu越少 比如儲存時間字段採用varchar型別與datatime型別對比 3 盡量避免使用null 因為可為null的列使得索引 索引統計和值比較都更加複雜 實際細節 1 整型 tinyint,smallin...
MySQL效能優化之表結構優化
第一正規化 屬性 字段 的原子性約束,要求屬性具有原子性,不可再分割 第二正規化 記錄的惟一性約束,要求記錄有惟一標識,每條記錄需要有乙個屬性來做為實體的唯一標識。第三正規化 屬性 字段 冗餘性的約束,即任何字段不能由其他字段派生出來。外來鍵解決設計原則 在資料冗餘和處理速度之間找到合適的平衡點 資...