mysql存储手机号为什么不用bigint?

2021/7/26 19:09:04

本文主要是介绍mysql存储手机号为什么不用bigint?,对大家解决编程问题具有一定的参考价值,需要的程序猿们随着小编来一起学习吧!

在使用utf8字符编码的情况下:

char(11) 用来存储手机号,会占用11 bytes
bigint 用来存储手机号,会占用 8 bytes
varchar(11)用来存储手机号,会占用 12 bytes

从容量和速度上看,bigint是最好的选择。

从扩展性上看,如果有国际区号,业务上也不会带着国际区号去查询,国际区号也可以放在另一列。

因此,为什么不使用bigint存储手机号呢?

手机号一般是要加索引的吧。。bigint你用了like索引就失效了

1.首先,手机号的本质是字符串而不是数字,只是恰巧长得像数字而已。(网上百度的,我也不知道三大运行商是怎么储存的)

2.字符串可以通过LINK去匹配,查询很方便。

3.字符串可以去匹配尾号或者首号。

4.在32位的某些应用中,bigint太大,会溢出,要进行各种转换,很麻烦。

5.手机号可能有-(座机),用int存不了。
char(32)varchar(32)
占用空间固定 32 字符(如果数据长度不够 32 将用空格补齐)跟随实际存储内容长度,但不超过 32
空格处理检索时会去掉尾部空格(数据本身有空白符也会被去掉)不会对空格处理
是否记录字段长度是。额外拿出空间记录字段数据长度(字符数)
适用场景存储的数据长度基本一致,不需要空格,eg 手机号、UUID、密码加密后的密文数据长度不一定,长度范围变化较大的场景

bigint的优势有:

更小的空间占用;
更高的操作效率(待验证);
支持更多的操作,比如between and操作;
VARCHAR的优势:

灵活;设计时候可以指定最大长度,存储时,存多少占用多少;
CHAR的优势:

效率比varchar更高;
假设我们将字段内容设计为 地区编码(4位)+手机号或者区号座机号(11位)的格式,那么该字段内容固定位15位长度:

空间:

bigint:8字节
VARCHAR:15字节
CHAR:15字节
bigint > varchar = char

效率猜测:

bigint > char > varchar

扩展性:

bigint:最多19位,实际使用15位,还有至少3位扩展空间(最高位如果拿来用时,其他位是有可能溢出的)
varchar:扩展性根据创建时候指定
char:没有扩展性
varchar > bigint > char

测试结果反转了我对操作效率的认知,实际为:

varchar >= char > bigint;

这样一来,char唯一可能的优势(效率)就不复存在了,bigint的优势也只剩下:

空间占用;
支持between and操作;
对于bigint的优势,对其进行分析:

空间占用:对于一个存放4位区号(不太可能,这里取4位为了计算最大的空间占用差距)和11号码的bigint和varchar,一个号码bigint 8Byte,varchar 15Byte,差距7Byte,假设中国是精确的十三亿人口,每人存放一条手机号码信息:差距就是:9100000000Byte,换算一下不到8.5GB,数据冗余备份共3个副本的话,就是25.5GB;节省的空间相当有限,因为其本身占用空间就不大,相信这个空间节省很难打动一个拥有13亿数据量的应用,将手机号存储切换至bigint;
这还是考虑到4位区号的情况下,如果不考虑区号,不计算副本,空间节省将变成不到3.7GB;实在难以让人心动;

支持between and操作这个优势,varchar也能使用正则表达式来实现相同的功能;或许在这一点上,bigint效率会高于varchar?这也许又是另一个话题了,但无论如何,bigint始终没有达到我对插入、查询方面的效率改进的预期;

综上,bigint没有足够多的优势打动我去使用bigint存储手机号,虽然很不甘心,当初次萌生这个想法的时候是相当兴奋的,觉得好像发现了新大陆,但是不得不将使用bigint存放手机号这个想法给打消;或许下次我应该试试使用int来存储手机号;

不存储区号;如果需要区号,分库或者分表的要求是非常合理的;甚至服务器本身都不会在同一个地区;
省略手机号开头的1(国内还没有看到1以外的数字开头的手机号,国外情况未知),这样就只剩下10位了,依然不够,第二位从0到9分库分表,还剩下9位,这对于int来说,能够存储了;
我一直认为对于数字的处理,交给数字类型比较好,所有才会有这样的想法,int对比varchar总该有性能提升吧;当然这样做,也有局限性:

实现起来变麻烦了,不过对于13亿数据量来说本身就应该分表了,一张表200w数据后就可能操作起来显著变慢;可是涉及到所有有手机号的字段都需要建立0~9 10个分表,这实在是代价有点大;也不能varchar和int混用,否则int那点可能存在的效率上的优势会被转换消化掉;

没有扩展性,如果将来手机号演变为2开头,那就麻烦啦;当然按照人口发展规律,可能性不大;但是另一个恐怖的念头展现在我脑海中了,那就是物联网,如果要给每个接入物联网的设备一个唯一号码呢?那int实现的扩展性将是致命的;

分析下来,int或许有些许性能优势,但其带来的复杂度和扩展上的劣势让我根本都不必动手,就打消了念头了;唉,也许这就是为什么大多数公司选择varchar存储手机号的原因吧;



这篇关于mysql存储手机号为什么不用bigint?的文章就介绍到这儿,希望我们推荐的文章对大家有所帮助,也希望大家多多支持为之网!


扫一扫关注最新编程教程