摘要：有个网友去面试了字节，被问了这么一道题，20亿手机号存储，选Int还是string？varchar还是char？为什么？
有个网友去面试了字节，被问了这么一道题，20亿手机号存储，选Int还是string？varchar还是char？为什么？
他支支吾吾回答了几句，好像看起来，面试官面色凝重，对他不是很满意，果然最后还是挂了。。。
本文跟大家聊聊我的思路。
20亿数据，用Int存储存在哪些问题？面试官的隐藏考察点日常开发避坑点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类型)需先转字符串再模糊匹配，效率暴跌。
保真：数字、符号、前导零全能存，原样保留。灵活：支持模糊查询、国际号码，扩展无忧。省心：无需担心溢出或格式转换问题。CREATE TABLE user_tab (id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT COMMENT '用户ID',phone_number VARCHAR(20) NOT NULL COMMENT '手机号',PRIMARY KEY (id),UNIQUE KEY idx_phone (phone_number)) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_Unicode_ci COMMENT='用户表';面试的时候，面试官主要考察候选人的一些业务扩展性、数据容错性、思考问题全面性等能力。我们先通过：为什么用 VARCHAR(20) 而不是 VARCHAR(11)，来给面试官秀一波肌肉~~
2.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对比，总成本仍可接受）。所以面试官期待的答案公式
合理长度 = 基础需求 + 国际扩展 + 容错缓冲当然，这个不是固定答案，主要还是面试的时候，你回答面试官的思路和表达，最好体现你有这几个方面的思考：业务扩展性、数据容错性、思考问题全面性。
2.2 极端场景
如果手机号是纯数字，并且第一位不是0的话，可以用BIGINT的，但是永远不要使用INT。通过这些极端场景的举例，也体现你思考问题全面性的一个能力。
设计手机号存储的时候，有哪些需要避的坑的。
主要有这几个吧：
3.1 字段长度设计过小
用 VARCHAR(11) 只存纯数字，遇到 +8613822223333（14位）直接截断。
用 VARCHAR(20) 兼容国际号、分机号（如 13822223333#123）。'
3.2 字符集和排序规则
使用 utf8 字符集，无法存储 emoji 或特殊符号
用 utf8mb4 + utf8mb4_unicode_ci，兼容所有 Unicode 字符（如 + * #）。
3.3 索引设计不当
未对手机号加唯一索引，导致重复数据。
添加 UNIQUE 约束：ALTER TABLE user ADD UNIQUE INDEX idx_phone (phone);3.4 数据清洗与校验缺失
用户输入 138-2222-3333 或 138 222 23333，直接存储导致格式混乱。
入库前统一清洗：移除空格、横杠等符号，只保留 + 和数字。
正则校验：例如 ^+?\d{8,20}$（允许带 + 号的 8~20 位数字）。
3.5 忽视隐私与安全
明文存储手机号，泄露用户隐私。
加密存储：使用 AES 加密或数据库内置加密函数。
脱敏显示：查询结果返回 138****3333。
3.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}$";来源：天哥教育
