MySQL 里存手机号用什么类型，这个问题我在不同场合被问过至少几十次。每次看对方的建表语句，十有八九是bigint，问的人还会补一句：手机号不就是 11 位数字吗，bigint最大能存 19 位数字，型号完全够，为什么不行？这个问题问得一点不傻——它触及的是数据库设计里最容易被忽略的一层：字段类型不是给数字本身分类的，是给业务语义分类的。手机号长得像数字，但它在数据库里要承担的是“编号”的职责。

这篇文章不打算停留在“应该用 varchar”这种结论层面。我会把bigint方案为什么会出问题、出了什么问题、以及生产环境里怎么选型、老表怎么迁，都拆开讲一遍。适合刚入门的后端开发、正在做表设计评审的技术人，也适合面试前想把这个高频问题吃透的人。

1. 手机号是“编号”不是“数字”：bigint 用错在建模层

1.1 你见过谁对手机号做加减乘除吗

先问一个很直白的问题：手机号在业务代码里参与过哪些运算？等值查询、范围查询、去重、关联、排序，基本就这些。再想想有没有对手机号做过+1、-1、求平均值、求和？正常人不会写WHERE phone + 1 = 13800000001，也不会有产品经理说“我要看所有手机号的平均值”。

数据库字段类型的选择，本质上是在告诉数据库“这个数据的语义是什么”。bigint是整数类型，它传递的语义是“这是一个数值，可以做算术运算”。但手机号在所有业务场景里都被当作一个标识符来用：查询某个用户、关联订单、统计某号段的用户数。标识符不具备数值的运算意义，它只是一个“对象名”。用bigint存手机号，等于把一个名词硬塞给了数值类型，数据库不懂你的业务，但它会用整数的规则来对待它。

1.2 字段类型真正要表达的是语义

这个道理放到其他字段上也成立。订单号通常是一串纯数字，但你见过有人用bigint存订单号吗？有过经验的人一定见过翻车现场：订单号超过int上限溢出、前导零被吞掉、导出到 Excel 后数字变科学计数法。身份证号更典型，18 位数字最后一位可能是 X，谁用数值类型存谁倒霉。银行卡号虽然纯数字，但长度经常超过 19 位，bigint直接溢出。

这些例子背后的规律是一致的：凡是“长得像数字的编号”，都不应该按数字来存。手机号、订单号、身份证号、银行卡号、车牌号、快递单号，本质都是编号，不是数值。编号的特点是：长度固定或基本固定、不需要算术运算、可能需要保留格式细节（加号、分隔符、前导零）、未来可能扩容。这些特点指向的都是字符串类型。

1.3 bigint“很能存”是误会：长度足够不代表类型合适

有人会较真：bigint最大存 19 位数字，手机号 11 位，长度完全够，为什么不能存？这是把“存储能力”和“语义准确性”混为一谈。bigint确实能放下 11 位数字，但放得下不等于放得对。就像你能用马克杯装红酒，杯子没漏，但品酒的人不会这么干——因为在合适的容器语义下，你失去了观察挂杯、香气这些该有的信息。

数据库设计也一样。你用bigint存手机号，等于主动丢弃了“手机号是号码、可能要处理格式和国际化”这个信息。这个信息在建模阶段丢了，后面想补回来，就得靠应用层各种CAST、CONVERT、正则校验硬找补，成本远比一开始选对类型高。

2. bigint 存手机号，我在生产环境里见到的真实事故

2.1 前导零：国际号码一来就原形毕露

国内手机号目前不会以 0 开头，所以很多人觉得前导零问题是杞人忧天。但业务一旦碰到国际号码，bigint会静悄悄地丢掉最前面的 0。比如某些国家或地区的手机号、区号本身就带前导零，存成数字后 0 直接消失，数据对不上。

我接手过一个做跨境服务的项目，老表里手机号就是bigint。海外用户注册时提交的号码带+号、空格和中划线，应用层为了塞进bigint不得不做一次“清洗”——把这些格式符全删掉，再转成数字。结果很多号码因为超过bigint精度，尾号变成 0，用户收到验证码都收不到。后来排查到根因，就是字段类型选错了，导致格式处理和精度丢失双重问题。

2.2 类型成了“作弊入口”：算术运算引发的号段统计翻车

bigint字段很容易诱导开发同事写出一些“偷懒”逻辑。我见过一个统计脚本，想筛出某运营商的号段用户，写的是WHERE phone >= 13800000000 AND phone <= 13899999999。写这个脚本的同事觉得挺聪明：手机号是数字，直接拿数字区间筛不就完了。问题在于，一旦号段格局变化——比如新号段出现、携号转网、虚拟运营商号段混入——这种硬编码数字区间的代码就全面失守。

更隐蔽的坑是隐式类型转换。某个业务接口把前端传来的手机号参数直接和bigint字段比较，MySQL 查询优化器发现字段是数值类型，会尝试把字符串参数转换成数值再比较。转换过程中如果参数带着+86或者空格，结果会非常诡异，甚至可能命中错误的数据。这些坑不是字段存不下数据，而是类型设计给了错误操作的空间。

2.3 加密存储与脱敏：bigint 连门都进不去

这几年隐私合规要求越来越高，手机号是最典型的敏感个人信息。很多系统的做法是：数据库不存明文，存加密后的密文；查询时用哈希值做精确匹配。场景一变，bigint直接出局——AES 加密输出的是二进制或 Base64 字符串，长度远超 8 字节，你不可能塞进bigint。

我见过一套更典型的方案：手机号在库里拆成两列，一列存密文用于解密展示，一列存 SHA-256 哈希值用于等值查询。哈希值是固定 64 位十六进制字符串或 32 字节二进制，两种都跟bigint不沾边。到这个阶段，如果你还在琢磨“bigint 能不能存手机号”，答案已经变成“不是能不能，而是连参与资格都没有了”。

2.4 非手机号数据混存：座机、400、+86 的格式灾难

业务永远比想象中复杂。你以为存的是手机号，实际上 CRM 或客服系统里还要存座机号、400 热线、带分机号的联系方式。座机号是“区号-号码”结构，400 电话是“400-xxx-xxxx”，国际号要带+号和国家码。这些格式bigint一概不认。

一个真实场景：某个后台管理系统允许用户填写“联系电话”，字段定义时按手机号做了bigint。结果用户在备注里填“010-12345678”，应用层转换直接报错；用户填“+1 202-555-0100”，转换后得到一个毫无意义的数字。最终只能紧急加一个contact_note字段兜底，数据也没法做统一统计。这就是典型的类型设计没有为业务多样化留余地。

2.5 格式化展示和报表里的类型转换地狱

手机号在界面上几乎很少以裸数字形式出现。要么脱敏成138****9537，要么按 3-4-4 分段展示。varchar存的数据，SQL 里直接LEFT、RIGHT、CONCAT就能处理；bigint存的数据，你写每条 SQL 前都得先CAST(phone AS CHAR)，一不小心就报转换错误。

报表导出也是重灾区。数据平台导出的 Excel 里，11 位数字的手机号会被识别成数值，显示成科学计数法，运维同事每次导出后都要手动调格式。你说这不是字段类型的锅？其实源头就在这里——字符串类型的数据不会触发 Excel 的数值识别机制。为了一个“顺手存了数字”的偷懒，把一堆下游工作全拖下水。

3. 把几种典型方案放在同一张对比表里看

3.1 一张表看清五种存法

手机号字段在主流的 MySQL 实践里，常见方案大致有五种。我用一张表把它们的核心差异摆出来，方便你直接对照：

注意，表格里的“存储空间”只是字段本身的估算。真实行存储还要算上varchar的长度前缀（0 到 2 字节）、行格式的变长字段标记、以及可能的碎片，这些差异在业务量级下完全可以忽略。

3.2 存储空间真相：省下的那几字节不值得你操心

很多坚持bigint的人，真实理由其实是“数值类型省空间、性能好”。这个说法得掰开算一下。bigint固定 8 字节，varchar(20)在 utf8mb4 字符集下，每个汉字按 4 字节计，但手机号是纯 ASCII 数字，实际每个字符只占 1 字节，20 字符最多 20 字节，再加上 1 字节长度前缀，约为 21 字节。一条记录差 13 字节左右。

假设你有 5000 万用户，一张表差了 6.5 亿字节，约 620MB。听起来不少是吧？但现代服务器磁盘按 TB 计，数据库内存缓冲池按 GB 计，这 620MB 分摊到一张几千万行的表里，往往只占整个表体积的几个百分点。为了省这点空间，搭上前面说的格式、语义、加密扩展性问题，账完全是算反的。

3.3 索引和查询差异：varchar 做等值匹配并不比 bigint 慢

有人担心varchar索引比bigint慢。手机号场景下，查询几乎都是等值匹配：WHERE phone = '138****9537'，或者配合=精确查唯一索引。MySQL 的 B+ 树对定长、短字符串的等值查询性能非常稳定，和整数索引的差距在业务层面可以忽略。真正会拉开差距的是模糊查询，比如LIKE '%138%'这种无法走索引的写法——但这类查询在手机号场景本来就该用专门的搜索方案或倒排索引，跟字段类型关系不大。

另外，手机号字段通常要建唯一索引。varchar(20)建唯一索引没问题，字符集排序规则用utf8mb4_general_ci或 MySQL 8.0 默认的utf8mb4_0900_ai_ci都行。如果业务对大小写敏感有要求，用utf8mb4_bin更严格。手机号是数字，大小写问题影响极小，选默认规则即可。

4. 生产环境手机号字段设计的推荐做法与老表迁移

4.1 基线方案：varchar(20) 为什么比 char(11) 更保险

先给结论：国内单一业务，我推荐varchar(20)，而不是char(11)。理由有三条。

第一，char(11)把“只能存 11 位纯数字国内手机号”写死在了表结构里。一旦业务决定支持海外号码——哪怕是只加一个+86前缀——你就要 ALTER TABLE 改字段长度，而 MySQL 改大字段长度虽然通常不需要重建整个表（取决于字符集），但在大表上仍可能是耗时操作，需要谨慎评估。

第二，varchar(20)兼容+86 13800000000、8613800000000等常见国际格式，长度余量刚好覆盖，不用为了某一种格式反复改表。第三，varchar按实际长度存储，国内号码存 11 个字符，海外号码存 16、17 个字符，空间开销都是按实际内容走的，不会有太多浪费。

建表时顺手加两个约束，能让方案更完整：

CREATE TABLE user_info ( user_id bigint unsigned NOT NULL AUTO_INCREMENT, phone varchar(20) DEFAULT NULL COMMENT '手机号，支持国际格式', PRIMARY KEY (user_id), UNIQUE KEY uk_phone (phone) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci;

4.2 分场景的字段类型决策，不只看手机号长度

我把不同业务的取舍整理成几条经验，拿到具体项目可以直接套：

• 纯国内 C 端 App：varchar(20)+ 应用层正则校验（1 开头，11 位数字）。不要轻易在数据库层做 CHECK 约束，因为 MySQL 的 CHECK 在 8.0.16 之前不真正生效，而且业务规则变化时改 CHECK 反而麻烦。
• 涉足海外业务：varchar(32)或varchar(64)。E.164 标准下号码最多 15 位数字，加上+和国家码，32 位已经富余，64 位则给展示用的空格、分隔符留足空间。
• 强隐私合规，计划做加密存储：直接上两列方案——phone_plaintext varbinary(64)存密文，phone_hash char(64) CHARACTER SET ascii存 SHA-256 哈希，等值查询走哈希列。此时明文列甚至可以不建索引，避免密文泄露风险。
• 客服工单、联系人管理等多格式场景：字段名不要叫phone，叫contact，类型varchar(64)，接受座机、400、国际号、备注格式混存，展示时不强制格式化，查询时单独拉一个“是否手机号”标记列来分流。

4.3 已经用了 bigint：迁移流程和校验脚本怎么写

如果你手里已经有一张bigint存手机号的表，别慌，迁移方案比较成熟，核心就四步：建新列、校验、转换、切换。

第一步，先加一个可空的新列：

ALTER TABLE user_info ADD COLUMN phone_new varchar(20) NULL AFTER phone;

第二步，写校验脚本，把旧列里能正常转成 11 位手机号的行先标记出来。这一步很关键，因为历史脏数据一定会出现——有的是位数不对，有的是被bigint精度吃掉尾号，有的混入了座机号。我的习惯是先跑一遍统计：

-- 检查非标准数据 SELECT COUNT(*) AS total_count, SUM(CASE WHEN phone BETWEEN 10000000000 AND 19999999999 THEN 1 ELSE 0 END) AS valid_count, SUM(CASE WHEN phone < 10000000000 THEN 1 ELSE 0 END) AS short_count, SUM(CASE WHEN phone > 19999999999 THEN 1 ELSE 0 END) AS weird_count FROM user_info;

第三步，把合法数据填充到新列，并做格式统一。比如统一去空格、统一补+86还是不加，团队内部需要先定一个规范：

UPDATE user_info SET phone_new = CONCAT('+86', CAST(phone AS CHAR)) WHERE phone BETWEEN 10000000000 AND 19999999999;

第四步，确认无误后建唯一索引、改应用层读写 SQL、灰度切换、最后删除旧列。这里面最容易踩的坑是“唯一索引建不上”——因为旧数据本身就有重复或异常值。所以建唯一索引前一定要先查重：

SELECT phone_new, COUNT(*) AS cnt FROM user_info GROUP BY phone_new HAVING cnt > 1;

有重复就先把重复数据合并或清洗掉，再建索引。

4.4 两个连带问题：手机号做唯一标识和换绑场景

手机号还有一个很容易被忽略的坑：它不应该是用户唯一业务键。手机号会换绑、会注销、会被运营商回收重新分配。你拿手机号当主键或全局唯一标识，一旦某个号码被回收并分配给新用户，系统就会把两个不同用户的数据串起来，这是线上事故级别的问题。

正确做法是：主键用自增bigint或雪花 ID，手机号只是用户的一个属性。如果业务要求“一个手机号只能注册一次”，给手机号列加唯一索引就够了——这个唯一索引表达的是“当前有效性”，不表达“历史归属唯一性”。换绑场景还要考虑一个连带问题：用户换了手机号之后，老号码如果被别人注册，唯一索引能不能放行。答案是能，只要你把“手机号 + 用户状态”放在一起做唯一约束，或者干脆在换绑时更新手机号字段，让唯一索引始终约束的是当前生效的映射关系。

5. 面试官到底想听什么：从一道题看数据库建模思维

5.1 这个问题的考察点不是存储，是抽象能力

现在回头看“mysql 存储手机号为什么不用 bigint”这个问题的标准答案：手机号在业务语义上是编号，不是数值，需要用字符串类型存储，保留格式、兼容国际号码，并为加密扩展留空间。这些点面试官能背下来，但他真正想听的是你分析字段类型时的思路。

我建议任何开发者在拿到表设计需求时，先做一次“三问”：

1. 这个字段在业务里承担什么角色？是标识符、是度量值、还是状态枚举？
2. 这个字段未来有哪些操作？等值查询、范围查询、排序、聚合、还是只在界面上展示？
3. 这个字段可能的取值空间和格式是什么？固定长度吗、允许特殊字符吗、会跨国界吗？

把这三问过一遍，类型选择基本不会错。手机号走一遍：标识符角色、几乎只有等值查询、格式多样且可能跨国——答案自然偏向varchar。

5.2 我给评审提出的手机号字段检查清单

在系统设计评审环节，看到有表要存手机号，我会按下面这张清单逐项过：

1. 字段类型不是整数，且长度足以容纳“当前业务可能的手机号格式”。
2. 字段是否加唯一索引，唯一索引的粒度是否符合“当前生效号码”的约束。
3. 是否设计了脱敏展示方案，明文手机号是否只暴露给必要场景。
4. 是否了解加密存储的演进路径，新表是否已经预留了哈希列或加密列的兼容性。
5. 是否明确手机号不作为主键，换绑、注销、号码回收时系统行为可预期。
6. 字段注释里是否写清楚了格式规范，比如“统一存储为 E.164 不带分隔符”或“国内号不加 86”。

这套清单不重，但每一项都能拦住一次线上事故。我在很多项目里看到过：手机号字段类型选对之后，还是因为格式不统一、唯一索引和换绑逻辑冲突、导出科学计数法这类问题反复返工。类型只是第一关，字段规范是第二关。

5.3 一点个人经验

我自己写表结构时有个小习惯：凡是纯数字但永远不会参与计算的字段，一律不用整数类型。这条经验帮我避开了不少坑。有一次评审某项目的用户表，同事用bigint存手机号，我看了眼表结构，顺手问了一句“你们后续要支持海外用户吗”，回答是“年底可能要做国际版”。我们当场把字段改成了varchar(20)，两周后产品就提了国际号段需求，同事回来专门道谢。

最后再分享一个扩展思路：如果你的业务已经进入强隐私合规阶段，不妨把手机号相关的设计从“字段类型”提升到“数据治理”层面——底层存储、查询链路、脱敏展示、日志脱敏、数据导出、备份加密，每一环都要单独过一遍。手机号用string还是数字，只是这条完整链路的起点。把起点选对，后面每条路都会顺很多。