對比MySQL中int、char以及varchar的性能
網(wǎng)絡(luò)上有許多似是而非的“謠言”,當然都不是惡意,絕大部分都是開發(fā)者不愿意自己主動研究,反而輕信其他人的信口之言。
關(guān)于數(shù)據(jù)庫的謠言也有不少,比如“int性能比char高很多”。
我最近針對int、long、char、varchar進行了一次性能測試,發(fā)現(xiàn)它們其實并沒有太大的性能差距:
備注:c8=char(8), s8=varchar(8), i8=(bigint), c4=char(4), s4=varchar(4), i4=char(4)
100w行無索引情況下查詢:
執(zhí)行[c8查詢]20次, 平均耗時312.0ms
執(zhí)行[s8查詢]20次, 平均耗時334.3ms
執(zhí)行[i8查詢]20次, 平均耗時276.95ms
執(zhí)行[c4查詢]20次, 平均耗時354.95ms
執(zhí)行[s4查詢]20次, 平均耗時340.45ms
執(zhí)行[i4查詢]20次, 平均耗時291.1ms
創(chuàng)建索引:
c8索引耗時2439ms
s8索引耗時2442ms
i8索引耗時1645ms
c4索引耗時2296ms
s4索引耗時2303ms
i4索引耗時1403ms
有索引情況下查詢:
執(zhí)行[c8查詢]10000次, 平均耗時0.271ms
執(zhí)行[s8查詢]10000次, 平均耗時0.2354ms
執(zhí)行[i8查詢]10000次, 平均耗時0.2189ms
執(zhí)行[c4查詢]10000次, 平均耗時0.303ms
執(zhí)行[s4查詢]10000次, 平均耗時0.3094ms
執(zhí)行[i4查詢]10000次, 平均耗時0.25ms
結(jié)論:
無索引:全表掃描不會因為數(shù)據(jù)較小就變快,而是整體速度相同,int/bigint作為原生類型稍快12%。
有索引:char與varchar性能差不多,int速度稍快18%
在數(shù)據(jù)存儲、讀寫方面,整數(shù)與等長字符串相同,varchar額外多了一個字節(jié)所以性能可能會些許影響(1/n)。
在數(shù)據(jù)運算、對比方面,整數(shù)得益于原生支持,因此會比字符串稍快一丁點。
若采用索引,所謂整數(shù)、字符串的性能差距更是微乎其微。
在實際開發(fā)中,許多開發(fā)者經(jīng)常使用char(1)、char(4)這樣的字符串表示類型枚舉,這種做法在我看來屬于最佳方案,因為這種做法在存儲空間、運算性能、可讀性、可維護性、可擴展性方面,遠勝于int、enum這種數(shù)據(jù)類型。
相關(guān)文章
一文讀懂navicat for mysql基礎(chǔ)知識
Navicat是一個強大的MySQL數(shù)據(jù)庫管理和開發(fā)工具。Navicat為專業(yè)開發(fā)者提供了一套強大的足夠尖端的工具,但它對于新用戶仍然是易于學(xué)習(xí)。本文重點給大家介紹navicat for mysql基礎(chǔ)知識,感興趣的朋友一起學(xué)習(xí)吧2021-05-05MySQL中between...and的使用對索引的影響說明
這篇文章主要介紹了MySQL中between...and的使用對索引的影響說明,具有很好的參考價值,希望對大家有所幫助。如有錯誤或未考慮完全的地方,望不吝賜教2023-07-07