写在开头

昨天在技术群里看到个老哥心态崩了。说是去字节二面面试官抛了个场景题：“我有 亿个使用者手机号。请你设计一个程序，支持毫秒级查询手机尾号。”

老哥一听，这也太简单了张口就来：“在 MySQL 建个索引。或者用 LIKE '%' 呗。”

面试官当场就笑了：“ 亿数据，你用 LIKE？这是要全表扫描把数据库炸穿吗？就算你建了普通索引，B+ 树的最左前缀原则也不认后缀啊。再想想，”

老哥汗流浃背，支支吾吾半天：“那…，上 ES？”

从面试官摇头来看。“为了查个尾号，你让我搭一套 ES 集群？这硬件成本、维护成本，还有数据同步的延迟怎么算？杀鸡用牛刀，”

这道题其实是架构设计里典型的“照妖镜”。它考的根本不是 SQL 语法，而是你对“异构索引”、“分布式路由”还有“存储成本”的权衡。话说回来，

今天咱们就扒开这 亿数据的外衣。看看怎么从架构层面把性能榨干。

至于痛点一，海量数据下的查询效率低下

为什么会出现这种痛点？

• 全表扫描耗时过长：B+树索引只支持从左到右匹配。当你需要按尾号查询时会导致索引失效，全表扫描。
• I/O 瓶颈：即使使用 SSD，也无法在毫秒级完成亿级数据的遍历。话说回来，
• 并发压力大：单台数据库无法承载高并发访问。一旦触发广播查询会瞬间炸掉连接池。

一、找死流：LIKE % / 暴力索引

SELECT * FROM users WHERE phone LIKE '%1234'

结局：Dba 提刀赶来你的工位可能保不住了。

原因：B+树索引遵循“最左前缀原则”。尾号匹配完全违背该原则，导致索引无效，全表扫描。话说回来，亿级数据，即便全是 SSD，也得几十分钟才能完成一次扫描。毫秒级，梦里啥都有。

二、入门流：反转大法好

"既然索引不支持从右往左查，那我就把数据倒过来存"

• Spoiler： 存手机号时顺手存一个反转字符串。例如将"13812345678" 存成"87654321231"
• 效果： 此时可以用*reversed_phone LIKE '%8765%' 实现前缀匹配，从而让B+树发挥作用。
• 痛点： 单表亿行仍需要几十 G 的索引文件；B+树层高增加导致 IO 成为瓶颈； 话说回来，并发处理仍受限于单台实例。

三、进阶流：分库分表 + 异构索引

1) 必须分库分表。但要避免广播查询

• 常见做法错误： 按 User_ID 分库后如果需要按尾号查询，就不知道目标所在库，从而导致向所有分片同时发起查询——广播。这会瞬间炸掉连接池与带宽。

2) 建立异构索引表

• 方案主要： 主表保持按 ID 分片；单独建一张映射表，只保存.
如何切分： 不要使用 Hash。因为尾号本身就是数字且均匀分布；建议直接切#张# 表,路由算法为suf % #张# = table_index.效果： 查?#张#=1234%#张#=…，请求直接打到对应单表，无需跨库调用。即使总量巨大，每张子表只有万行左右，可谓轻盈如羽。*隐藏雷区*: 面试官可能问“会返回多少条结果？”——答案是每种四位尾号平均约10万条记录！一次性返回全部会导致 OOM 或网络爆带宽.- 解法 ->- 强制分页：加上AORDER BY user_id DESC LIMIT N;,业务上只展示最新注册或有限数量使用者；若需更深分页可考虑分析型数据库或额外收费服务.

四、兜底流：Redis 怎么用？

• *别提布隆过滤器*: 尾号范围内数千种组合都必然存在用于空集检测显得无意义.
*正确姿势*: 用 Redis 缓存热点尾号的数据前几条。如,把这些热点请求从主数据库脱离出来；非热点或深度翻页则直接走异构索引表.注意：Redis 的持久化与内存限制，需要根据热点占比做容量规划，否则易出现 OOM 或持久化失败.
如果你的业务需要完整列表页，可结合分页 + 游标 + Redis 热点缓存，实现高可用与低延迟双重保障.

下次面试再问这个。用下面这段话明显优势：

" 面试官，这个问题的本质是海量数据的非分片键查询. 我不会搞昂贵的 ES，而是采用'异构索引表 + 覆盖索引'' 的方案。怎么说呢，建立一张独立的索引表，利用手机尾号天然的离散性。直接'取模路由'' 到 张分表中，避免全库广播扫描。为防止单次查询数据量过大打爆内存，我会严格限制'分页查询'. 对于热点尾号。利用 Redis 缓存'首页数据'进行兜底。这是一套成本最低、性能最高且完全可落地的架构方案。"

写在最终

简单讲架构设计，从来不是堆砌组件。老实说，能用 MySQL 解决的不必走 ES；能用取模解决的不必走 Hash。把复杂留给自己，把简单留给机器，这是高手之道。

兄弟们。如果产品经理非要让你支持 “模糊搜索任意中间位”（比如 %12%)，除了提桶跑路，你还有什么招？评论区聊聊，