简介：这份 MySQL 手机号归属地数据包面向需要做号码归属查询、客户区域分析或数据库练习的开发者与数据分析人员，提供手机号与省份、城市之间的关联表，可用于按号码精确查询、按地区分组统计用户数量，以及结合其他业务表做联表分析。包内共 1 个 SQL 文件，压缩包约 2.22MB，导入 MySQL 后即可围绕号码、省份、城市等字段编写查询语句，适合作为 SQL 基础练习与批量数据处理的小型数据集。已有 269 人学习，说明其在号码归属地查询场景中具有一定参考价值。数据覆盖面较全，能帮助读者快速验证查询逻辑、理解分组聚合与条件筛选的写法，并据此搭建客户分布统计、区域运营分析等练习场景；使用时也需注意个人信息保护，在合规前提下加密存储、限制访问权限。
1. 一个手机号查归属地，为什么值得单独保存成一张 MySQL 表
注册风控要判断手机号归属地和用户填的收货地址是否对得上，客服后台要在工单抬头显示“广东·深圳·移动”，运营做地域分布报表还得按省聚合。最早这几处都是直接调第三方接口，按次计费不说，QPS 一上来就被限流，接口一超时整条注册链路跟着卡住。后来把这份号段库导入 MySQL，查询时按 7 位前缀做等值匹配，单次查询零点几毫秒，接口费用直接归零，报表还能用GROUP BY province直接出。
这份资源是一个整理好的号段数据包，主体是 SQL 文件，核心表把手机号前 7 位映射到省、市、运营商，另外带了行政区划编码和邮编字段。它解决的是“离线、可批量、不依赖外部服务”的归属地查询需求，适合做风控、CRM、订单地域统计、客服工单的后端开发；不适合需要精确到街道甚至基站级别定位的场景，那种得上运营商能力。它最核心的价值在于：把按次调用的成本，变成一次导入、长期本地查询。
2. 表结构拆解：号段、省市、运营商三个维度怎么摆
拿到 SQL 文件后，我一般先不看数据，先看SHOW CREATE TABLE。号段库看着简单，但字段类型和索引一旦选错，后面几百万次查询都在为这个决定买单。这一章把主表的字段设计、索引策略和数据规模三件事说清楚，看完你应该能判断手上这份库要不要改造。
2.1 主表字段设计：从 7 位号段到省市运营商
主流号段库的主表结构基本是同一个思路：一行代表一个号段，字段横向铺开省市和运营商。我在实际项目里落地时用的 DDL 大致如下，和资源包里的结构差异很小，主要补了prefix_len和updated_at两个字段。
CREATE TABLE `phone_segment` ( `id` INT UNSIGNED NOT NULL AUTO_INCREMENT, `prefix` VARCHAR(7) NOT NULL COMMENT '号段前缀，7位精确号段或3位兜底号段', `prefix_len` TINYINT UNSIGNED NOT NULL COMMENT '前缀长度，3或7，用于最长匹配排序', `province` VARCHAR(32) NOT NULL DEFAULT '' COMMENT '省份，如 广东', `city` VARCHAR(48) NOT NULL DEFAULT '' COMMENT '城市，如 深圳', `isp` VARCHAR(16) NOT NULL DEFAULT '' COMMENT '运营商，移动/联通/电信/虚拟', `area_code` CHAR(6) NOT NULL DEFAULT '' COMMENT '行政区划编码，关联地区表', `zip_code` CHAR(6) NOT NULL DEFAULT '' COMMENT '邮编，可空', `updated_at` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (`id`), UNIQUE KEY `uk_prefix` (`prefix`), KEY `idx_province_city` (`province`, `city`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci COMMENT='手机号段归属地';这里有几个取舍值得说明。prefix用VARCHAR(7)而不是INT，是因为手机号是标识符不是数值，存成整数会丢前导零，也会在导出 Excel 时被科学计数法吃掉；用变长而不用CHAR(7)，是为了让 3 位兜底号段不浪费尾部空格，CHAR在比较时虽然会忽略尾部空格，但在某些客户端展示和CONCAT场景下容易出怪问题。prefix_len是个冗余字段，纯粹为了让“先查 7 位、查不到再查 3 位”这件事能用一条ORDER BY解决，不用在应用层写两段逻辑。
uk_prefix唯一索引不只是为了约束，它同时是查询索引，等值匹配直接命中 B+ 树，这是整个方案快的根本原因。idx_province_city是给报表用的，做“按省统计注册量”这类聚合时能避免全表扫。
提示：如果资源里的原始表没有
prefix_len，用UPDATE phone_segment SET prefix_len = CHAR_LENGTH(prefix);一条语句补齐即可，几秒钟的事，别嫌麻烦。
2.2 索引与字符集：等值匹配和前缀扫描的分水岭
索引这件事在号段库上有一个非常典型的分水岭：同样是查138开头的号，写法不同性能差两个数量级。原因是 MySQL 的 B+ 树索引只能做最左前缀匹配，WHERE prefix = '1380013'能走索引定位到一行，而WHERE prefix LIKE '138%'虽然理论上也能用索引，但在实际执行计划里经常退化成范围扫描加回表，WHERE LEFT(phone,7) = '1380013'则是把函数套在列上，索引直接失效。
所以正确的链路是：在应用层把手机号截成 7 位，再用参数去和prefix做等值比较。数据库只负责精确匹配，不做字符串运算。这一点在批量查询时尤其明显，我压测过 10 万条手机号的批处理，等值写法比LIKE写法快了一个数量级。
字符集上，utf8mb4是必须的，虽然理论上省市的汉字用utf8（三字节）也能存，但现在 MySQL 8 默认就是utf8mb4，建表时不显式指定COLLATE utf8mb4_general_ci，跨库 JOIN 或临时表排序时容易报Illegal mix of collations。而且有些号段库里带了少数民族地区的地名，utf8mb4兜得住。
压缩也值得一提。号段表是典型的“写一次读一万次”的只读表，字符串重复度极高（一个省几十万行都是同一个值），把表设成ROW_FORMAT=COMPRESSED KEY_BLOCK_SIZE=8能让磁盘占用降到三分之一左右，缓冲池里能多装几倍数据。代价是写入慢一点，但这份表本来就不怎么写。
2.3 数据规模与分区：百万行到底要不要分表
很多人第一次看到号段库会下意识想分表。实际算一笔账就清楚了：手机号前 7 位，理论上限是 10^7 = 1000 万个组合，但实际分配的号段远没有这么多，一份比较全的库大概在 30 万到 80 万行之间，加上 3 位兜底行也不会超过 100 万。100 万行、每行不到 200 字节，整表 200MB 上下，压缩后更小，InnoDB 缓冲池随便一台 4G 内存的机器都能全量缓存。
这个体量下分库分表是纯负担。真正的瓶颈不在这张表，而在调用方——如果每次查归属地都要走一次网络往返，那 0.2ms 的查询也会被 1ms 的 RTT 拖到 5ms。所以要优化的方向是减少往返次数，不是切分数据。批量查询、应用层缓存、本地内存映射，这三个手段的收益比任何分表方案都大。
注意：如果拿到的库超过 300 万行，先别急着分区，先
SELECT prefix, COUNT(*) FROM phone_segment GROUP BY prefix HAVING COUNT(*) > 1;查一下是不是有重复导入。我遇到过一份库被导了三遍，行数虚高，去重后只剩 40 万。
真要做归档的话，按prefix_len分层就够了：7 位精确号段一张表，3 位兜底号段一张表，兜底表通常只有几百行，可以常驻应用内存，连接数据库的查询量能砍掉一大半。这个拆法比按省或者按号段首位分区实用得多，因为业务查询永远是从精确到兜底，不会跨省跳着查。
3. 导入与跑通：把 SQL 文件导入 MySQL 并验通第一条数据
结构看明白之后，接下来就是让它跑起来。这一章从建库、导入、校验一路写到查询封装，照着敲一遍，本地环境十分钟能出结果。
3.1 建库建表：一份可复现的 DDL
先建库。字符集必须显式指定，别依赖服务器的默认配置，换台机器就容易出乱码。
-- 建库：显式指定字符集，避免依赖服务端默认配置 CREATE DATABASE IF NOT EXISTS `phone_db` DEFAULT CHARACTER SET utf8mb4 DEFAULT COLLATE utf8mb4_general_ci; USE `phone_db`; -- 地区维表：可选，用于省市校验和层级展示 CREATE TABLE `phone_area` ( `area_code` CHAR(6) NOT NULL COMMENT '行政区划编码', `parent_code` CHAR(6) NOT NULL DEFAULT '000000' COMMENT '上级编码，省级为000000', `name` VARCHAR(48) NOT NULL COMMENT '地区名称', `level` TINYINT NOT NULL DEFAULT 1 COMMENT '1省 2市 3区县', PRIMARY KEY (`area_code`), KEY `idx_parent` (`parent_code`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci;地区表不是必须的，但强烈建议留着。号段表里的area_code一旦和地区表对不上，就说明这份数据在某次整理中错位了，这比省市文字写错更难发现——文字错了人眼能看出来，编码错位只能靠 JOIN 校验。
建完表之后的导入，用命令行比用图形工具靠谱，因为图形工具经常偷偷改编码。
# 导入号段数据，强制指定客户端字符集为 utf8mb4 mysql -h 127.0.0.1 -u root -p \ --default-character-set=utf8mb4 \ phone_db < phone_segment.sql--default-character-set这个参数是关键，它决定了客户端发送给服务端的字节流按什么编码解释。源文件如果是 GBK 整理的（很多老数据包都是），这个参数要改成gbk，导入完成后表里才是正确的汉字；反过来，如果源文件是 UTF-8 而你指定了 GBK，就会得到一堆问号和乱码，而且这种损坏是不可逆的，只能重导。导入前用file -i phone_segment.sql或编辑器的编码检测确认一下，能省掉一次翻车。
导入完成后立刻做三件事：看行数、看前几行、看有没有乱码。
-- 1. 行数量级是否符合预期（几十万级） SELECT COUNT(*) AS total FROM phone_segment; -- 2. 抽样看中文是否正常 SELECT prefix, province, city, isp FROM phone_segment ORDER BY RAND() LIMIT 5; -- 3. 检查是否存在乱码行（问号、替换字符） SELECT COUNT(*) AS bad_rows FROM phone_segment WHERE province LIKE '%?%' OR province LIKE '%�%';第三条如果返回非 0，就别往下走了，直接回去查编码。这一步看似多余，实际上比后面接口返回一堆???再去排查要省太多时间。
3.2 三条查询路径：精确、兜底、区间
数据到位之后，查询逻辑按“精确优先、兜底其次”的顺序设计。手机号的号段粒度并不统一，大部分新号段能精确到 7 位，但一些老号段和虚拟运营商号段只能到前 3 位甚至前 4 位，所以库里同时存在两种长度的prefix。
-- 路径一：7位精确匹配，命中 uk_prefix 唯一索引 SELECT province, city, isp, prefix_len FROM phone_segment WHERE prefix = '1380013' AND prefix_len = 7 LIMIT 1; -- 路径二：一条语句同时尝试7位和3位，按长度倒序取最长匹配 SELECT province, city, isp, prefix_len FROM phone_segment WHERE prefix IN (LEFT('13800138000', 7), LEFT('13800138000', 3)) ORDER BY prefix_len DESC LIMIT 1;路径二是实际项目里最常用的写法。IN里放两个常量，MySQL 会做两次等值查找，然后在结果集上做一次两行的排序，代价可以忽略。ORDER BY prefix_len DESC保证 7 位命中时优先返回 7 位的结果，只有 7 位查不到时才退回 3 位。LIMIT 1是保险，防止有人往表里插了重复号段导致返回多行。
注意LEFT('13800138000', 7)这里的函数作用在常量上，不是作用在列上，MySQL 在优化阶段会把常量表达式折叠成一个字面量，索引照样生效。这和WHERE LEFT(prefix, 7) = ?完全是两回事，后者才是索引杀手。
第三种路径是区间匹配，适用于号段以起止范围存储的库（有些整理版是start_num/end_num两个字段）。这种表查起来要用范围条件，索引要建在start_num上：
-- 号段以区间形式存储时的查法，需在 start_num 上建索引 SELECT province, city, isp FROM phone_range WHERE start_num <= 13800138000 AND end_num >= 13800138000 LIMIT 1;区间表的好处是存储紧凑，坏处是范围查询的回表次数不可控，而且必须保证区间之间不能重叠，否则会查出多行。如果资源给的是这种结构，我的建议是导入后跑一遍转换，展开成前缀表，查询侧统一用等值匹配，别让业务代码去处理区间重叠的边界。
3.3 用存储函数封装一个 get_attribution
如果调用方是报表工具、BI 平台或者不方便改代码的场景，可以在库里封装一个函数，把匹配逻辑收进数据库。
DELIMITER $$ CREATE FUNCTION `fn_get_attribution`(p_phone VARCHAR(20)) RETURNS VARCHAR(128) DETERMINISTIC READS SQL DATA BEGIN DECLARE v_result VARCHAR(128) DEFAULT NULL; -- 只接受11位纯数字，+86、空格、短横线一律拒绝 IF p_phone IS NULL OR CHAR_LENGTH(p_phone) <> 11 OR p_phone REGEXP '[^0-9]' THEN RETURN NULL; END IF; SELECT CONCAT_WS('|', province, city, isp) INTO v_result FROM phone_segment WHERE prefix IN (LEFT(p_phone, 7), LEFT(p_phone, 3)) ORDER BY prefix_len DESC LIMIT 1; RETURN v_result; END$$ DELIMITER ;函数体里有两处值得说。第一处是入参校验，REGEXP '[^0-9]'拦掉带+86前缀、带空格、带横线的输入——这几种情况在真实数据里出现频率极高，尤其是从 Excel 粘贴过来的号码。不校验的话函数会带着+8613800138000去匹配，LEFT(...,7)取到的是+861380，必然查不到。
第二处是CONCAT_WS，它会把NULL值跳过而不像CONCAT那样整串返回NULL，省市字段有缺失时不会把整个结果吞掉。DETERMINISTIC声明是为了让 MySQL 在开启 binlog 的实例上允许创建函数。
提示：MySQL 8 默认开启 binlog，创建函数时如果报
This function has none of DETERMINISTIC...，要么加上DETERMINISTIC，要么让 DBA 设置log_bin_trust_function_creators=1。前者更稳妥，别去动全局参数。
函数验证直接SELECT fn_get_attribution('13800138000');就行。但要注意，函数内部是逐行调用，做全表扫描式的批量调用（比如UPDATE t SET loc = fn_get_attribution(phone)）会把 100 万次单行查询串起来跑，慢得让人怀疑人生。批量场景还是走应用层，下一章讲。
4. 工程化落地：从单表查询到服务层缓存
单机跑通只是起点。真接到业务里，调用量往往集中在少数几个热号段上，而且一次请求可能要查几十上百个号码。这一章讲三件事：怎么把数据搬到离调用方更近的地方、批量查询怎么写、接口返回什么结构。
4.1 应用层预加载：把号段表塞进内存
号段表是典型的只读字典，非常适合在应用启动时全量加载进内存。40 万到 80 万行，每行三个短字符串，用HashMap<String, Attribution>存，堆内存占用大概 60 到 100MB，对一个正经的 Web 服务来说完全可接受。
@Component public class PhoneAttributionCache { /** 7位精确号段，预分配容量避免扩容抖动 */ private final Map<String, Attribution> exactMap = new HashMap<>(1 << 20); /** 3位兜底号段，通常只有几百条 */ private final Map<String, Attribution> shortMap = new HashMap<>(1024); @Resource private JdbcTemplate jdbcTemplate; @PostConstruct public void load() { // 只查一次，按前缀长度分流到两张内存表 jdbcTemplate.query( "SELECT prefix, prefix_len, province, city, isp FROM phone_segment", rs -> { String prefix = rs.getString("prefix"); Attribution attr = new Attribution( rs.getString("province"), rs.getString("city"), rs.getString("isp")); if (rs.getInt("prefix_len") == 7) { exactMap.put(prefix, attr); } else { shortMap.put(prefix, attr); } }); } /** 先7位后3位，返回 null 表示库里没有这个号段 */ public Attribution lookup(String phone) { if (phone == null || phone.length() != 11) { return null; } Attribution attr = exactMap.get(phone.substring(0, 7)); return attr != null ? attr : shortMap.get(phone.substring(0, 3)); } }@PostConstruct保证在 Bean 初始化完成后执行一次加载，之后所有查询都是纯内存操作。exactMap的初始容量给到1 << 20（约 104 万），是因为 HashMap 扩容时要 rehash 全表，一次给足能省掉几十毫秒的启动抖动和一堆临时对象。
lookup的顺序就是前面说的最长匹配：先拿 7 位去精确表找，找不到再用 3 位去兜底表找。这个方法在单机上是纳秒级，比走一次 Redis 还快。
代价是数据更新不及时。号段库不是天天变，但新号段放出后确实需要补录，所以我在实际项目里会加一个定时任务，每天凌晨重新拉一次全量并做Map的原子替换——用volatile引用指向一个新的 Map，比在旧 Map 上逐个 put 安全得多，查询方完全无感。
4.2 批量查询与 IN 的坑
不是所有场景都能预加载。比如一个独立的对账服务，一天只跑一次，启动就加载 80 万行太浪费，这时候走数据库批量查更合适。
-- 一次查1000个号段，用 IN 批量拉取，应用层再组装 SELECT prefix, province, city, isp FROM phone_segment WHERE prefix IN ( '1380013','1380014','1380015' /* ... 由应用动态拼接占位符 */ );批量查询最容易出的问题是IN列表太长。MySQL 对IN的元素个数没有硬限制，但一条 SQL 几万个参数会导致解析开销剧增、网络包超限、甚至触发max_allowed_packet报错。我的经验值是一次 1000 个，分批提交，既能减少往返次数，又不会把单条语句撑爆。
第二个坑是只查 7 位会漏数据。批量查的时候如果只IN了 7 位前缀，那些只有 3 位号段的号码就查不出来，应用层拿到空结果会误判为“无效号段”。正确做法是把 3 位前缀也一并IN进去，或者在应用层对空结果做一次 3 位兜底补查。
第三个坑是用IN加ORDER BY FIELD()来保序。数据量小的时候没问题，上万条时FIELD()的比较开销很可观，不如查回来在内存里按Map重组，代码还更清晰。
如果想让数据库层再快一点，可以把号段表导成一张内存表或者临时表，让 MySQL 把它留在内存里：
-- 只读字典表，数据量小，内存表能省掉大量磁盘IO CREATE TABLE `phone_segment_mem` ( `prefix` VARCHAR(7) NOT NULL, `province` VARCHAR(32) NOT NULL, `city` VARCHAR(48) NOT NULL, `isp` VARCHAR(16) NOT NULL, PRIMARY KEY (`prefix`) ) ENGINE=MEMORY DEFAULT CHARSET=utf8mb4;MEMORY引擎的表重启即失，只适合作为启动时从磁盘表灌进来的副本。它用的是定长存储，VARCHAR实际会按最大长度占位，所以字段别开太长。
4.3 接口封装与返回结构
对外的接口设计上，有两件事必须做：一是把“查不到”和“查到了但字段为空”区分开，二是把置信度透出去。
@RestController @RequestMapping("/api/phone") public class PhoneController { @Resource private PhoneAttributionCache cache; @GetMapping("/attribution") public Result<PhoneAttributionVO> attribution(@RequestParam String phone) { // 统一清洗：去空格、横线、+86 前缀 String normalized = phone.replaceAll("[\\s-]", "") .replaceFirst("^\\+?86", ""); if (!normalized.matches("\\d{11}")) { return Result.fail("PARAM_INVALID", "手机号格式不正确"); } Attribution attr = cache.lookup(normalized); if (attr == null) { // 查不到不代表号码非法，只代表库里没有这个号段 return Result.ok(PhoneAttributionVO.unknown()); } PhoneAttributionVO vo = new PhoneAttributionVO(); vo.setProvince(attr.getProvince()); vo.setCity(attr.getCity()); vo.setIsp(attr.getIsp()); // 3位兜底命中的，精确度只到省份，标记出来给前端 vo.setPrecision(normalized.substring(0, 7).equals(attr.getPrefix()) ? "CITY" : "PROVINCE"); return Result.ok(vo); } }清洗逻辑放在接口层是最省事的，所有调用方都受益。replaceFirst("^\\+?86", "")处理国际区号，顺序上要先清洗再校验，不然带+86的合法号码会被matches("\\d{11}")直接判死。
precise字段或者叫置信度字段，是我被业务方追问过之后加的。3 位兜底只能定位到省份，如果接口不说明，前端就会把省份当城市显示，出现“广东省·广东省”这种诡异结果。返回结构里带上精度等级，前端怎么展示就是他们的事了。
5. 避坑与排查：导入、索引、判定三类高频翻车场景
号段库这东西逻辑简单，但简单的东西出问题往往最难查，因为大家默认它不会错。这一章记录五个我实际踩过或者帮别人排查过的坑，按现象、原因、解决三段写。
5.1 数据导入阶段：乱码、截断、前导零
坑一：导入后省市全是问号或者“锟斤拷”
现象：SELECT * FROM phone_segment LIMIT 5;出来的省字段是???或者一长串锟斤拷，但用编辑器打开 SQL 文件看是正常的。
原因：源文件是 GBK 编码，导入时没有指定--default-character-set=gbk，客户端按 UTF-8 解释字节流，再以 UTF-8 写进utf8mb4的列，字节序列被破坏。锟斤拷是 UTF-8 的替换字符被再做一次 GBK 解码的典型产物，看到它基本可以直接判定是双重编码。
解决：先确认源文件编码，再决定参数。命令行的--default-character-set一定要显式写，别依赖my.cnf里的默认值。导入后跑一次乱码检查 SQL，返回 0 才继续。已经导坏的，TRUNCATE重来，编码损坏不可逆。
坑二：手机号变成 1.38E+10 或者少了开头的 0
现象：从 Excel 或者 CSV 整理的中间数据导进来，prefix字段出现1.38E+10这样的科学计数法，或者 11 位号码变成 10 位。
原因：号码在源文件里被当成数值处理了。Excel 对超过 11 位的数字默认用科学计数法显示并丢精度，CSV 如果没有给字段加引号，导入工具的数值推断也会造成同样结果。
解决：源数据一律按文本处理，CSV 里每个号码用双引号包裹；导入时目标列必须是VARCHAR不能是INT；如果只有 Excel 文件，先把列格式设成文本再另存为 CSV。这个坑我踩过一次，40 万行数据全废，重导花了半天。
5.2 查询阶段：索引失效与错误匹配
坑三：加了索引查询还是很慢
现象：prefix上明明有唯一索引，WHERE LEFT(phone, 7) = '1380013'这类查询却要两三秒，EXPLAIN显示type=ALL。
原因：函数套在了列上。LEFT(phone, 7)让 MySQL 无法使用phone或prefix上的索引，只能逐行计算结果再比较，本质是全表扫描。
解决：把计算放到参数侧。WHERE prefix = LEFT(?, 7)里的?是常量，优化器会折叠；更好的做法是在应用层截好再传，SQL 里只出现WHERE prefix = ?。改完之后EXPLAIN应该是type=const，rows=1。
坑四：LIKE '138%'查出来的结果和预期不一致
现象：用LIKE前缀匹配，查138开头的号码，结果里混进了1380、13800等不同长度的行，或者查询结果为空但表里明明有数据。
原因：LIKE是字符串模式匹配，不区分号段语义。表里同时存在 3 位和 7 位两套prefix时，LIKE '138%'会把138、1380、1380013全部命中，返回多行；如果业务只要最精确的那一条，就会拿到错误结果。
解决：不用LIKE做号段查询，统一改成IN加ORDER BY prefix_len DESC LIMIT 1的最长匹配。如果历史代码已经这么写了，加AND prefix_len = 7至少能先止血。
5.3 业务判定阶段：号段失真与空结果
坑五：归属地对，运营商经常对不上
现象：用户投诉“我明明是联通号，你们显示移动”。抽查几十个号码，归属地省市全对，运营商字段有 5% 到 10% 是错的。
原因：携号转网。号码的号段归属是出厂时分配的，转网之后号码不变、运营商变了，任何静态号段库都反映不出来。另外 170、171 这类虚拟运营商号段，底层承载网络和品牌运营商是两回事，不同整理版的标注口径也不统一。
解决：接受这个事实，别把isp当权威字段。业务上如果需要准确的当前运营商，只能走运营商侧的能力接口或者短信回执这类动态手段。号段库的isp只作为默认值展示，或者在返回结构里明确标注为“号段归属运营商”。至于虚拟号段，建议在表里单独标一个isp='虚拟'，避免和三大运营商混在一起做统计。
坑六：查不到就判成非法号码
现象：新放号的用户注册被拦截，提示“手机号不存在”，用户反复重试无果。
原因：号段库版本旧，新分配的号段不在库里，查询返回null，业务代码把null直接当成了非法号码。号和号段是两回事，号段库查不到只能说明“未知”，不能说明“不存在”。
解决：把“格式合法”和“号段已知”拆成两个判定。格式校验用正则，号段查询失败时返回“未知归属地”而不是拒绝。同时把未命中的号段记到一张phone_segment_miss表里，定期捞出来补录，这样库的覆盖面会随着业务量自己长起来。
6. 二次开发：号段增量更新与多端复用
这份库到手之后，真正花时间的不是导入，而是让它“活下去”。号段资源是按批往下发的，一批新号段放出来，旧的库就开始产生未命中。我的做法是建一张phone_segment_miss表，把所有未命中的号码前缀记下来，按周聚合，人工确认后补进主表。补录脚本很简单，但能省掉“为什么新用户查不到归属地”这类反复出现的问题。
-- 未命中记录表：只留前缀和出现次数，不存完整号码 CREATE TABLE `phone_segment_miss` ( `prefix` VARCHAR(7) NOT NULL COMMENT '未命中的前缀', `hit_count` INT UNSIGNED NOT NULL DEFAULT 1 COMMENT '累计出现次数', `first_seen` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, `last_seen` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (`prefix`), KEY `idx_count` (`hit_count` DESC) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; -- 补录时按出现次数排序，优先处理高频号段 SELECT prefix, hit_count FROM phone_segment_miss ORDER BY hit_count DESC LIMIT 50;只存前缀不存完整号码，是为了避免把用户手机号落到一张没人管的表里。hit_count用ON DUPLICATE KEY UPDATE hit_count = hit_count + 1累加，一条语句搞定写入和计数。按周看一次这张表，出现次数超过阈值的号段基本可以确认是真实在用的新号段，补进去就行；出现一两次的可能是脏数据，可以先放一放。
多端复用是另一个改造方向。移动端做离线归属地展示，不可能每次都请求服务端，把表导成紧凑的二进制或者 JSON，打进 App 包里是常见做法。我一般会导出一份按前缀排序的定长记录文件，每行前缀(7) + 省ID(2) + 市ID(2) + 运营商ID(1)，用area_code映射表换中文，整个文件能压到 3MB 以内，客户端用二分查找，几十微秒出结果。
验证上我有个固定动作：改完查询逻辑或者补录数据之后，抽 200 条已知归属的号码跑一遍对照，其中一定要包含几个边界样本——3 位兜底命中的老号段、虚拟运营商号段、带+86前缀的输入、位数不对的脏数据。这几类覆盖到了，回归基本不会漏。
有一个坑到现在我都记得。早期为了图快，我直接在旧Map上做put更新，结果更新过程中有请求读到了半新半旧的数据，同一个号段前后两次查询返回了不同的省，排查了半天才发现是并发可见性问题。从那以后我每次改这类内存字典，都强制走“新建一份 + 原子替换引用”的流程，宁可多占一倍瞬时内存，也不在旧结构上原地改。希望这份号段库在你手上也能少走这些弯路，帮到你。
本文还有配套的精品资源，点击获取
