MySQL優化之 表策略和索引

2021-05-21 23:16:13 字數 972 閱讀 3524

本文試圖從資料表建立的策略(schema)和索引的角度描述優化選擇。

資料越小越好。選擇滿足需求的最小資料型別。通過節省更多的磁碟空間,記憶體以及cache,使得你的資料庫更快。

選擇簡單的型別。整形值相比於字元型的代價較小,因為字符集和校對規則的關係。比如說應該儲存日期和時間,而不是個字串;ip位址也應該用數字儲存。

盡可能的避免null。盡量把資料列定義為not null。可為null的列使得索引的實現更加複雜,查詢更難優化。 整型

tinyint  smallint  mediumint  int  bigint

位元組  1              2                3              4       8

unsigned屬性可以修飾以上型別,而像int(11)後面的11只是輸出顯示的位數,並不影響資料儲存和計算。

實數float和double是浮點型,分別佔4,8位元組。如果要儲存確切的數,需要decimal型別。

decimal型別以bit string的形式儲存。盡量用前者,因為decimal消耗更多的儲存空間和計算時間。

字串型別

不同的儲存引擎對於char和varchar的實現是不同的。

varchar:一般情況下varchar只儲存所需的位元組空間,不過當myisam設定了fixed 的row_format時例外。

varchar在資料前用1~2位元組來儲存實際資料的長度。不過對於儲存所需長度方法,當資料更新空間不夠時會變得麻煩。

資料中的前導和後附的空格都存入和可讀出。

char:     不儲存後面的空格。當儲存少量的字串或者資料長度較接近時,可以採用該型別。

盡量不使用blob和text型別。

當值可以確定時,可用enum代替字串型別。

孤立where位元組中的列。意思就是條件語句中要想用上index,則該列不能處於左邊的表示式中或函式中:如where id+1 = 5  。

對於過長的列使用字首索引

mysql索引使用策略和優化

1.1 索引選擇原則 較頻繁的作為查詢條件的字段應該建立索引 唯一性太差的字段不適合單獨建立索引,即使頻繁作為查詢條件 更新非常頻繁的字段不適合建立索引 不會出現在 where 子句中的字段不該建立索引 1.2 索引選擇原則描述 1.3 索引選擇注意事項 既然索引可以加快查詢速度,那麼是不是只要是查...

MySQL優化索引之雙表優化

建表sql create table if not exists class id int 10 unsigned not null primary key auto increment,card int 10 unsigned not null create table if not exists...

MySQL索引優化策略分析

explain的用法 執行計畫 explain select from pms product where id 1 組合索引一定是最左匹配原則 如果你在表上建立了很多組合索引,索引檔案膨脹,修改 刪除 更新會比較慢expalin的作用 type 查詢的效果從上到下越來越差 優勢 提高查詢速度 表連...