👉 这是一个或许对你有用的社群
🐱 一对一交流/面试小册/简历优化/求职解惑，欢迎加入「芋道快速开发平台」知识星球。下面是星球提供的部分资料：
《项目实战（视频）》：从书中学，往事上“练”
《互联网高频面试题》：面朝简历学习，春暖花开
《架构 x 系统设计》：摧枯拉朽，掌控面试高频场景题
《精进 Java 学习指南》：系统学习，互联网主流技术栈
《必读 Java 源码专栏》：知其然，知其所以然
👉这是一个或许对你有用的开源项目
国产Star破10w的开源项目，前端包括管理后台、微信小程序，后端支持单体、微服务架构
RBAC权限、数据权限、SaaS多租户、商城、支付、工作流、大屏报表、ERP、CRM、AI大模型、IoT物联网等功能：
多模块：https://gitee.com/zhijiantianya/ruoyi-vue-pro
微服务：https://gitee.com/zhijiantianya/yudao-cloud
视频教程：https://doc.iocoder.cn
【国内首批】支持 JDK17/21+SpringBoot3、JDK8/11+Spring Boot2双版本
前言
最近一位粉丝说，他去面试了字节，问了这么一道题，20亿手机号存储，选int还是string？varchar还是char？为什么？
他支支吾吾回答了几句，好像看起来，面试官面色凝重，对他不是很满意 ，果然最好还是挂了。。。
本文跟大家聊聊我的思路 。
20亿数据，用Int存储存在哪些问题？
面试官的隐藏考察点
日常开发避坑点
基于 Spring Boot + MyBatis Plus + Vue & Element 实现的后台管理系统 + 用户小程序，支持 RBAC 动态权限、多租户、数据权限、工作流、三方登录、支付、短信、商城等功能
项目地址：https://github.com/YunaiV/ruoyi-vue-pro
视频教程：https://doc.iocoder.cn/video/
1. 20亿数据，用Int或者BigInt能有在哪些问题？
1.1 int存得下11位数字嘛？
首先，我们都知道手机号，是11位的数字 ，比如13728199213.
在Java中，int是 32位，最大值为 2^31 - 1 = 2,147,483,647。约等于 2×10⁹。显然，如果用int，根本存不下 11位的手机号码 。
要想存得下，得用64位的Long类型 ，也就是对应数据库的bigInt。
1.2 数据完整性
例如手机号01324567890，用Long存会变成1324567890，直接破坏数据完整性。
Long phoneNumber =01324567890L; //编译报错，Java不允许前导0的Long整数并且，有时候，有些手机号可能包含国家代码如（+86），或者有些时候，是有连字符的，比如137-2819-9213. 这些原因都导致不能用整型类型存储。
1.3 查询麻烦
比如，你要查找，手机号是137开头的手机号号码，如果用BigInt(Long类型)需先转字符串再模糊匹配，效率暴跌。
基于 Spring Cloud Alibaba + Gateway + Nacos + RocketMQ + Vue & Element 实现的后台管理系统 + 用户小程序，支持 RBAC 动态权限、多租户、数据权限、工作流、三方登录、支付、短信、商城等功能
项目地址：https://github.com/YunaiV/yudao-cloud
视频教程：https://doc.iocoder.cn/video/
2. 用String有哪些好处
保真 ：数字、符号、前导零全能存，原样保留。
灵活 ：支持模糊查询、国际号码，扩展无忧。
省心 ：无需担心溢出或格式转换问题。
CREATE TABLE user_tab (
idBIGINTUNSIGNEDNOTNULL AUTO_INCREMENT COMMENT'用户ID',
phone_number VARCHAR(20) NOTNULLCOMMENT'手机号',
PRIMARY KEY (id),
UNIQUEKEY idx_phone (phone_number)
) ENGINE=InnoDBDEFAULTCHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci COMMENT='用户表';3. 面试官的隐藏考察点
面试的时候，面试官主要考察候选人的一些业务扩展性、数据容错性、思考问题全面性 等能力。我们先通过：为什么用 VARCHAR(20) 而不是 VARCHAR(11)，来给面试官秀一波肌肉~~
3.1 为什么用 VARCHAR（20） 而不是 VARCHAR（11）
我们就拿手机号来说，为什么更建议用 VARCHAR(20)，而不是VARCHAR(11)呢？
因为我们都知道，手机号是11位的，为什么不直接用VARCHAR(11)呢？
如果你日常开发中，就有思考数据容错性习惯 的话，就会想到：
如果遇到国际号码：+8613822223333（14位）
带国家码的号码：008613822223333（15位）
分机号：13822223333#123（超11位）
这些场景，都会导致VARCHAR(11)报错崩盘。
其次就是业务扩展性思考 ：VARCHAR(11)只能存纯11位数字，假设未来业务需要：
支持座机号（如010-62223333，含横杠）
支持虚拟号（如17012341234-5678）
支持其他登录方式（如邮箱+手机号混合存储）
因此，字段长度和类型需提前为业务变化留余地，避免频繁改表 。这就是日常开发中的，业务扩展性思维思考。
还有数据容错性思考 ，
输入不可控性 ：用户可能输入带空格/符号的号码（如138 2222 3333），直接存原始值更方便清洗。
设计妥协 ：若强制用VARCHAR(11)，需在代码层严格过滤非数字字符，增加复杂度。
还有思考问题全面性，比如存储成本思考 。
VARCHAR(11) ：最大占 11字节（utf8mb4下1字符占4字节，但数字和+号只占1字节）
VARCHAR(20) ：最大占 20字节
20亿数据相差仅约 18GB（和用BIGINT的16GB对比，总成本仍可接受）。
所以面试官期待的答案公式
合理长度 = 基础需求 + 国际扩展 + 容错缓冲当然，这个不是固定答案，主要还是面试的时候，你回答面试官的思路和表达 ，最好体现你有这几个方面的思考：业务扩展性、数据容错性、思考问题全面性。
3.2 极端场景
如果手机号是纯数字，并且第一位不是0的话，可以用BIGINT的，但是永远不要使用INT。通过这些极端场景的举例，也体现你思考问题全面性的一个能力 。
4. 日常开发避坑点
设计手机号存储的时候，有哪些需要避的坑的 。
主要有这几个吧：
4.1 字段长度设计过小
用 VARCHAR(11) 只存纯数字，遇到 +8613822223333（14位）直接截断。
用 VARCHAR(20) 兼容国际号、分机号（如 13822223333#123）。'
4.2 字符集和排序规则
使用 utf8 字符集，无法存储 emoji 或特殊符号
用 utf8mb4 + utf8mb4_unicode_ci，兼容所有 Unicode 字符（如 + * #）。
4.3 索引设计不当
未对手机号加唯一索引，导致重复数据。
添加 UNIQUE 约束：ALTER TABLE user ADD UNIQUE INDEX idx_phone (phone);4.4 数据清洗与校验缺失
用户输入 138-2222-3333 或 138 222 23333，直接存储导致格式混乱。
入库前统一清洗：移除空格、横杠等符号，只保留 + 和数字。
正则校验：例如 ^+?\d{8,20}$（允许带 + 号的 8~20 位数字）。
4.5 忽视隐私与安全
明文存储手机号，泄露用户隐私。
加密存储：使用 AES 加密或数据库内置加密函数。
脱敏显示：查询结果返回 138**** 3333。
4.6 风控校验
// 严格校验（11位纯数字，无国际码）
String regex = "^1(3[0-9]|4[579]|5[0-35-9]|6[2567]|7[0-8]|8[0-9]|9[0-35-9])\\d{8}$";
// 宽松校验（允许带国际码，如+86 13812345678）
String looseRegex = "^(\\+\\d{1,3})?1(3\\d|4[579]|5[0-35-9]|6[2567]|7[0-8]|8\\d|9[0-35-9])\\d{8}$";欢迎加入我的知识星球，全面提升技术能力。
👉 加入方式，“长按”或“扫描”下方二维码噢：
星球的内容包括：项目实战、面试招聘、源码解析、学习路线。
文章有帮助的话，在看，转发吧。
谢谢支持哟 (*^__^*）
扫一扫
617
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
