MySQL中int、char、varchar的效能淺談

sisyphsu發表於2018-09-15

網路上有許多似是而非的“謠言”,當然都不是惡意,絕大部分都是開發者不願意自己主動研究,反而輕信其他人的信口之言。

關於資料庫的謠言也有不少,比如“int效能比char高很多”。

我最近針對int、long、char、varchar進行了一次效能測試,發現它們其實並沒有太大的效能差距:

備註:c8=char(8), s8=varchar(8), i8=(bigint), c4=char(4), s4=varchar(4), i4=char(4)

100w行無索引情況下查詢:
執行[c8查詢]20次, 平均耗時312.0ms
執行[s8查詢]20次, 平均耗時334.3ms
執行[i8查詢]20次, 平均耗時276.95ms
執行[c4查詢]20次, 平均耗時354.95ms
執行[s4查詢]20次, 平均耗時340.45ms
執行[i4查詢]20次, 平均耗時291.1ms

建立索引:
c8索引耗時2439ms
s8索引耗時2442ms
i8索引耗時1645ms
c4索引耗時2296ms
s4索引耗時2303ms
i4索引耗時1403ms

有索引情況下查詢:
執行[c8查詢]10000次, 平均耗時0.271ms
執行[s8查詢]10000次, 平均耗時0.2354ms
執行[i8查詢]10000次, 平均耗時0.2189ms
執行[c4查詢]10000次, 平均耗時0.303ms
執行[s4查詢]10000次, 平均耗時0.3094ms
執行[i4查詢]10000次, 平均耗時0.25ms

結論:
無索引:全表掃描不會因為資料較小就變快,而是整體速度相同,int/bigint作為原生型別稍快12%。
有索引:char與varchar效能差不多,int速度稍快18%

在資料儲存、讀寫方面,整數與等長字串相同,varchar額外多了一個位元組所以效能可能會些許影響(1/n)。
在資料運算、對比方面,整數得益於原生支援,因此會比字串稍快一丁點
若採用索引,所謂整數、字串的效能差距更是微乎其微。

在實際開發中,許多開發者經常使用char(1)、char(4)這樣的字串表示型別列舉,這種做法在我看來屬於最佳方案,因為這種做法在儲存空間、運算效能、可讀性、可維護性、可擴充套件性方面,遠勝於int、enum這種資料型別。

相關文章