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

關于數據庫的謠言也有不少，比如“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這種數據類型。

《新程序員》：云原生和全面數字化實踐50位技術專家共同創作，文字、視頻、音頻交互閱讀

總結

以上是生活随笔為你收集整理的mysql varchar int_MySQL中int、char、varchar的性能浅谈的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。