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存不了。

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存储手机号的原因吧；