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?的文章就介绍到这儿,希望我们推荐的文章对大家有所帮助,也希望大家多多支持为之网!
- 2024-12-07MySQL读写分离入门:轻松掌握数据库读写分离技术
- 2024-12-07MySQL读写分离入门教程
- 2024-12-07MySQL分库分表入门详解
- 2024-12-07MySQL分库分表入门指南
- 2024-12-07MySQL慢查询入门:快速掌握性能优化技巧
- 2024-12-07MySQL入门:新手必读的简单教程
- 2024-12-07MySQL入门:从零开始学习MySQL数据库
- 2024-12-07MySQL索引入门:新手快速掌握MySQL索引技巧
- 2024-12-06BinLog学习:MySQL数据库BinLog入门教程
- 2024-12-06Binlog学习:MySQL数据库的日志管理入门教程