高效能MySql演化論 三 ID 標示符 的選擇

2021-08-27 14:40:55 字數 1654 閱讀 3542

在設計資料庫表結構的時候,通常情況下每張表結構都有乙個字段作為id,因為 id會被用來做查詢,join,fk等操作,所以id設計的好壞對效能的影響很大。

在為id選擇合適的型別的時候不僅需要考慮這種型別在資料庫中儲存所占用的空間,還需要考慮該型別在計算或者是值比較時的特性,例如bit型別儲存的時候是二進位制的形式,而在數字計算的上下文時,會被轉換成對應的十進位制形式。

對id進行join操作或者是被用來作為其他表的fk時,涉及的字段型別要保持完全的一致,即使型別都是整數,unsigned/signed這樣的微小細節也要保持一致,否則在效能方面可能會有意想不到的效能問題,這種問題往往又是難以被發現的。如果使用的storage engine 是innodb,則可以有效的防止關聯字段型別不匹配的問題,如果型別不匹配則會丟擲 異常「error 1005 (hy000): can』t createtable」(varchar(10)和varchar(20)會被認為型別是完全相同的)。

建立id時,要遵守「盡量最小型別原則」(在滿足以後需求變化的情況下,要選擇占用儲存空間最小的型別),例如 有一張儲存全國省份的表,對於這張種需求而言,tinyint比int更適合作為id的型別,雖然選用tinyint只是節省了3個byte, 但是在進行join操作或者是作為fk時,效能可能會有很大的提公升。

實際的應用開發中,id的型別往往是多樣的,例如int,varchar是比較常用的兩種型別,但是有些情況下也可以使用enum作為id的型別,下面的內容分別對這幾種型別進行描述

因為整數型別是一種簡單的型別,對比於字串它的處理更簡單速度更快,而且它還支援auto_increment特性,所以一般情況下它是作為id的首選型別

因為mysql處理字串要比整數消耗更多的儲存/記憶體空間,而且速度也相對較慢,所以應該盡量避免使用字串作為id的型別。

在無法避免字串作為id的型別時,往往會採用「隨機值」的策略來生成id的值,常用的方法包括uuid,md5, sha1.在這種情況下需要額外注意,因為隨機生成的id值可能會帶來以下三個問題:

(1) 在執行insert語句時意味著索引值會被任意寫到索引表的不同位置,這種對於磁碟的隨機訪問行為,將會導致插入操作的變慢,

(2) 在執行select操作時,因為邏輯相關的索引也被會被任意寫到索引表的不同位置,也會導致查詢的變慢。

(3) 對於資料庫提供的cache機制而言,這種隨機值的策略產生的影響也是比較大的。因為cache往往是基於「熱區」的原理來實現的,比如說索引表中有100個索引,你執行了多次的查詢的結果都是索引表中的20-30這部分的索引,那麼 mysql serve為了提高查詢效率會把20-30這部分索引的值放到cache中,如果你又有一些查詢的結果是在30-40 之間的,那麼server會對cache進行更新。如果是基於隨機的索引,意味著「熱區」的區間將會很大,這將導致cache的命中率受到影響,而且也會導致cache的不斷重新整理。

如果儲存uuid 值,則應該移除「-」符號;或者更好的做法是,用unhex() 函式轉換uuid 值為16 位元組的數字,並且儲存在乙個binary(16) 列中。檢索時可以通過hex()函式來格式化為十六進製制格式。

列舉

對於id來說,emum 和set 型別通常是乙個糟糕的選擇,儘管對某些只包含固定狀態或者型別的靜態「定義表」來說可能是沒有問題的。enum 和set 列適合儲存固定資訊,例如有序的狀態、產品型別、人的性別。沒有特殊需求,應該放棄這個選擇

高效能MySql演化論 三 ID 標示符 的選擇

在設計資料庫表結構的時候,通常情況下每張表結構都有乙個字段作為id,因為 id會被用來做查詢,join,fk等操作,所以id設計的好壞對效能的影響很大。在為id選擇合適的型別的時候不僅需要考慮這種型別在資料庫中儲存所占用的空間,還需要考慮該型別在計算或者是值比較時的特性,例如bit型別儲存的時候是二...

高效能MySql演化論 十一 常見查詢語句的優化

高效能mysql演化論 十一 常見查詢語句的優化,總結一下常見查詢語句的優化方式。1.count的作用 count table.filed 統計的該字段非空值的記錄行數 count 或者是count not nullable field 統計的是全表的行數 如果要是統計全表記錄數,count 效率會...

高效能MySql演化論 八 表以及索引的維護

為了擁有高效能的資料庫,建立良好的表結構以及索引是必不可少的,與此同時對於表以及索引的維護也很重要 資料庫表損壞的原因很多,作業系統問題,硬體問題,或者是手工的修改了mysql的資料檔案,都會導致表的損壞。當出現問題時可能會導致查詢行為的異常,具體的異常行為在不同版本的資料庫中都不同。當發現資料庫的...