手机号码归属地数据库自建实战：从号段映射到增量更新

简介：这份资源是面向开发者与数据分析人员的手机号码归属地数据库，以MySQL为存储载体，可用于号码归属查询、运营商识别及地域统计分析等场景。压缩包共2个文件，包含1个sql脚本与1个mdb数据文件，整体约8.27MB，sql文件便于直接导入MySQL建库建表，mdb文件则方便在Access等环境中查看原始数据。数据库记录量达38万条以上，覆盖号码对应的省份、城市与运营商信息，并可按需设计号码表、运营商表及省市表之间的关联结构，配合索引优化可支撑较大数据量的快速检索。已有732人学习下载，适合需要快速搭建归属地查询功能或研究号码地域分布的中级开发者参考使用。

1. 手机号码归属地数据库：一个被低估的“脏活”工程

做风控、做用户画像、做客服工单分派的人，迟早会撞上同一个需求：给一串手机号，判断它大概属于哪个省、哪个市、哪家运营商。很多人第一反应是“调个接口不就完了”，真上手才发现，接口按次计费、有 QPS 限制、断网就抓瞎，批量跑几十万条时账单比服务器还贵。于是自建一份手机号码归属地数据库成了绕不开的选项。它本质是一张“号段前缀 → 归属地/运营商”的映射表，核心难点不在查询，而在数据从哪来、怎么清洗、怎么更新、怎么在内存和磁盘之间做取舍。这篇写给准备自己落地这套东西的工程师，从表结构一路讲到批量查询和增量更新，中间该踩的坑我基本都踩过一遍。

2. 号段映射的底层逻辑与数据源选型

手机号归属地判断的根基是号段规划：国内手机号是 11 位，前 3 位是号段标识，早期 3 位就能定位运营商和省份，后来号码资源紧张，部分号段细化到前 7 位（号段 + HLR 标识）才能区分地市。这意味着你的数据库粒度必须至少支持 7 位前缀匹配，只存 3 位前缀的库在直辖市和部分省份会大面积出错。这一章先把“数据长什么样、从哪来、怎么选”讲透，不然后面写查询代码全是空中楼阁。

2.1 号段前缀到底要存几位

先明确一个事实：3 位前缀只能保证运营商级别大致正确，地市级精度必须靠 7 位。举个常见现象，同一个 3 位号段下，不同第 4 到第 7 位可能分属不同地市，只按 3 位查会把一批号码归到省会。我的做法是主键存 7 位前缀，同时保留 3 位前缀字段做降级兜底：7 位查不到时回退到 3 位，返回省级结果并标记精度为“省”。表结构大致如下：

CREATE TABLE phone_location ( prefix7 CHAR(7) NOT NULL COMMENT '7位号段前缀，主匹配键', prefix3 CHAR(3) NOT NULL COMMENT '3位号段，降级兜底用', province VARCHAR(32) NOT NULL COMMENT '省份', city VARCHAR(32) DEFAULT NULL COMMENT '地市，可能为空', carrier VARCHAR(16) NOT NULL COMMENT '运营商', precision TINYINT NOT NULL DEFAULT 2 COMMENT '1=省级 2=地市级', updated_at DATE NOT NULL COMMENT '数据版本日期', PRIMARY KEY (prefix7), KEY idx_prefix3 (prefix3) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

precision字段很关键，它让调用方知道这条结果是精确到市还是只到省，风控场景里“省级可信、市级存疑”和“市级可信”是两种处置策略。updated_at用于增量更新时判断哪些行需要刷新，别小看它，号段转网和携号转网会让旧数据悄悄失效。

2.2 数据源的三条路和各自代价

自建库的数据来源无非三类：公开号段规划整理、运营商公开资料汇总、商业数据采购。公开整理版更新慢、地市精度参差，但零成本、可离线；商业采购版精度高、带更新服务，但按年付费且授权范围要看清（能不能用于对外产品）。我一般会先用公开整理版搭出骨架，跑通查询链路，再评估是否值得为地市精度付费。选型时重点看三个指标：号段覆盖率（能否覆盖当前在用的全部 3 位号段）、地市准确率（抽样 1000 条人工核对）、更新频率（季度还是月度）。覆盖率低于 95% 的库直接放弃，否则线上会出现大量“未知归属地”。

2.3 存储形态：SQLite、MySQL 还是内存结构

查询量决定存储形态。日查询量在万级以下，SQLite 单文件足够，部署简单、零运维；十万级以上且要多进程共享，MySQL 或 PostgreSQL 更稳；如果是高并发只读场景（比如网关层实时判断），把映射加载进内存的哈希表是延迟最低的方案，7 位前缀做 key，内存占用大约每条 100 字节，百万级号段也就百来兆。我的常见组合是：离线批量用 SQLite，在线服务用内存哈希 + 定期从库刷新。下面这段是把 SQLite 数据加载进内存的骨架：

import sqlite3 def load_prefix_map(db_path): conn = sqlite3.connect(db_path) cur = conn.cursor() # 只取必要字段，减少内存占用 cur.execute("SELECT prefix7, prefix3, province, city, carrier, precision FROM phone_location") m7, m3 = {}, {} for p7, p3, prov, city, carrier, prec in cur: m7[p7] = (prov, city, carrier, prec) # 3位兜底表只保留省级信息，避免覆盖更精确的7位结果 if p3 not in m3: m3[p3] = (prov, None, carrier, 1) conn.close() return m7, m3

逻辑说明：7 位表是主查询表，3 位表只存省级兜底，且用if p3 not in m3保证先写入的省级记录不被后来的地市记录污染（因为 3 位表本身不承载地市信息）。参数上，precision=1表示省级兜底，调用方据此决定是否展示地市。加载完成后两个字典常驻内存，查询就是两次字典命中，延迟在微秒级。

3. 从原始号段表到可查询库的清洗流水线

拿到原始数据只是开始，真正耗时间的是清洗：字段不统一、地市名带“市”不带“市”、运营商叫法五花八门、重复号段、非法前缀。这一章给出一条可复现的清洗流水线，从原始 CSV 到入库，每一步都能单独跑、单独验证。

3.1 字段标准化：地市名和运营商名的归一

原始数据里“北京”“北京市”“北京市市辖区”可能同时出现，运营商有“移动”“中国移动”“CMCC”多种写法。归一化用映射字典最稳，别用正则硬猜。下面是一个可复用的归一函数：

PROVINCE_ALIAS = {"北京": "北京市", "内蒙古": "内蒙古自治区", "广西": "广西壮族自治区"} CARRIER_ALIAS = {"移动": "中国移动", "CMCC": "中国移动", "联通": "中国联通", "CU": "中国联通", "电信": "中国电信", "CT": "中国电信"} def normalize(row): prov = row["province"].strip() prov = PROVINCE_ALIAS.get(prov, prov) city = (row.get("city") or "").strip() # 去掉重复的“市”后缀，保留标准写法 if city.endswith("市市"): city = city[:-1] carrier = CARRIER_ALIAS.get(row["carrier"].strip(), row["carrier"].strip()) return prov, city or None, carrier

逻辑说明：别名表只覆盖高频变体，遇到表里没有的写法原样保留并在日志里打点，后续人工补表。city为空时返回None而不是空字符串，方便入库时区分“确实没有地市信息”和“字段缺失”。参数上，别名表建议单独放配置文件，方便运营同学维护，不用改代码。

3.2 前缀合法性校验与去重

清洗完字段还要校验前缀：必须是 7 位数字、首位为 1、第二位在 3 到 9 之间（这是号段规划的基本约束）。非法前缀直接丢弃并计数，重复前缀保留updated_at最新的一条。校验逻辑如下：

import re PREFIX_RE = re.compile(r"^1[3-9]\d{5}$") def validate_and_dedup(rows): seen = {} dropped = 0 for r in rows: p7 = r["prefix7"].strip() if not PREFIX_RE.match(p7): dropped += 1 continue # 同一前缀保留版本更新的记录 if p7 not in seen or r["updated_at"] > seen[p7]["updated_at"]: seen[p7] = r return list(seen.values()), dropped

逻辑说明：正则^1[3-9]\d{5}$同时约束了首位、第二位范围和总长度，比逐位判断更紧凑。去重时用updated_at比较，保证同一号段以最新数据为准。dropped计数要打日志，如果丢弃比例超过 5%，说明数据源格式有问题，得回头查源文件而不是硬跑。

3.3 批量入库与索引建立

清洗后的数据用executemany批量写入，单批 5000 条左右，太大容易撑爆事务日志，太小则 IO 次数多。入库后建prefix3索引，因为降级查询会走这个字段。入库脚本骨架：

def bulk_insert(conn, rows, batch=5000): sql = """INSERT OR REPLACE INTO phone_location (prefix7, prefix3, province, city, carrier, precision, updated_at) VALUES (?, ?, ?, ?, ?, ?, ?)""" data = [(r["prefix7"], r["prefix7"][:3], r["province"], r["city"], r["carrier"], 2 if r["city"] else 1, r["updated_at"]) for r in rows] for i in range(0, len(data), batch): conn.executemany(sql, data[i:i + batch]) conn.commit()

逻辑说明：INSERT OR REPLACE让重复前缀自动覆盖，配合前面的去重形成双保险。precision根据是否有地市自动判定，有地市记 2，无地市记 1。分批提交是为了控制单次事务大小，避免长事务锁表。参数batch在机械盘上建议 2000，SSD 上 5000 到 10000 都行。

4. 查询接口设计与批量匹配的性能取舍

库建好了，接下来是查询。单条查询和批量查询是两种完全不同的工程问题：单条追求低延迟，批量追求吞吐。这一章把两种场景的接口设计和性能取舍讲清楚，附上可复现的压测思路。

4.1 单条查询：前缀截取与降级策略

单条查询的核心是“先截 7 位查主表，查不到截 3 位查兜底表”。注意输入要先做清洗：去掉空格、横线、+86 前缀，非 11 位直接返回无效。查询函数：

def query(phone, m7, m3): phone = phone.strip().replace("-", "").replace(" ", "") if phone.startswith("+86"): phone = phone[3:] if len(phone) != 11 or not phone.isdigit(): return {"valid": False} hit = m7.get(phone[:7]) if hit: prov, city, carrier, prec = hit return {"valid": True, "province": prov, "city": city, "carrier": carrier, "precision": prec} hit3 = m3.get(phone[:3]) if hit3: prov, _, carrier, prec = hit3 return {"valid": True, "province": prov, "city": None, "carrier": carrier, "precision": prec} return {"valid": True, "province": None, "city": None, "carrier": None, "precision": 0}

逻辑说明：+86前缀处理放在长度校验之前，否则带前缀的号码会被误判为非法。7 位未命中时降级到 3 位，返回precision=1并置city=None，调用方据此决定展示粒度。完全未命中返回precision=0，表示号段不在库中，这种情况要打点监控，可能是数据源覆盖不足。

4.2 批量查询：分块、并发与内存控制

批量场景（比如一次导入十万条用户手机号）不能逐条查库，要把数据分块后在内存里跑，必要时多进程并行。分块大小按内存和 CPU 核数调，一般每块 1 万到 5 万条。下面是一个分块并行的骨架：

from concurrent.futures import ProcessPoolExecutor def query_chunk(args): phones, m7, m3 = args return [query(p, m7, m3) for p in phones] def batch_query(phones, m7, m3, chunk=20000, workers=4): chunks = [(phones[i:i + chunk], m7, m3) for i in range(0, len(phones), chunk)] results = [] with ProcessPoolExecutor(max_workers=workers) as ex: for part in ex.map(query_chunk, chunks): results.extend(part) return results

逻辑说明：ProcessPoolExecutor适合 CPU 密集的字典查询，但要注意m7、m3会被序列化到子进程，百万级字典序列化开销不小。如果字典很大，改用多线程（GIL 对纯字典查询影响有限）或把字典放共享内存更划算。参数workers建议不超过物理核数，chunk太小会让进程间通信开销占比过高。

4.3 压测：用真实号段分布而不是随机号

压测最容易翻车的地方是用随机 11 位数字造数据，结果大量号码落在库里没有的号段，测出来的延迟全是“未命中”路径，毫无参考价值。正确做法是从库里抽样真实号段，按命中比例构造测试集（比如 80% 命中 7 位、15% 命中 3 位、5% 未命中）。用timeit或locust跑，重点看 P99 而不是平均值。我的血泪经验是：平均值 0.1ms 但 P99 到 20ms，通常是某几个超大号段触发了字典扩容或缓存失效，得单独看长尾。

5. 避坑清单：号段数据落地时最容易翻车的五件事

这一章全是踩坑记录，每条按“现象 → 原因 → 解决”写，都是我在实际项目里遇到过的，新手照着排查能省不少时间。

5.1 直辖市号码地市字段大面积为空

现象：北京、上海、天津、重庆的号码查出来city全是None，只有省份。原因：原始数据里直辖市的地市字段本身为空或写成“市辖区”，清洗时被当成缺失处理。解决：在归一化阶段对四个直辖市做特殊映射，city直接填省份同名值（如“北京市”），precision记 2。别指望数据源自己修好，这类问题在公开整理版里非常普遍。

5.2 携号转网导致运营商判断错误

现象：用户投诉“我明明是联通号，你们显示移动”。原因：携号转网后号码的号段归属运营商和实际运营商不一致，号段库只能反映“号段初始分配”，无法反映转网后的真实状态。解决：在返回结果里加一个carrier_by_prefix字段，明确这是“号段归属运营商”而非“当前运营商”，业务侧需要真实运营商时走运营商接口或让用户自报。这个坑不解决，客服工单会一直错派。

5.3 3 位兜底表覆盖了 7 位精确结果

现象：部分号码明明库里有 7 位记录，查出来却是省级结果。原因：加载内存时先写 3 位表、后写 7 位表，或者 3 位表用了dict.update把精确记录覆盖了。解决：3 位表只写省级信息且用if p3 not in m3保护，7 位表独立存储，查询时严格先查 7 位。这个 bug 很隐蔽，因为大部分号码查出来是对的，只有少数号段出错，靠抽样很难发现，得写单测覆盖“7 位存在但 3 位也存在的号段”。

5.4 增量更新把整库锁死

现象：每月更新数据时，线上查询超时，监控告警。原因：直接对生产表做DELETE+ 全量INSERT，长事务锁表。解决：用影子表方案，新数据先写phone_location_new，写完用RENAME TABLE原子切换，切换瞬间完成，查询不受影响。切换前记得校验新表行数和抽样比对，别切了个空表上去。

5.5 号段前缀补零导致匹配失败

现象：某些号段查不到，但库里明明有。原因：原始 CSV 里前缀被 Excel 当成数字，前导零丢失或变成科学计数法。解决：读 CSV 时强制所有前缀字段按字符串读（dtype=str），入库前用正则校验长度，长度不对的直接进异常队列人工处理。这个坑在 Windows 上导出的 CSV 里尤其常见，别问我是怎么知道的。

6. 增量更新与数据质量监控的落地技巧

数据落地不是一锤子买卖，号段会新增、会调整，库得能持续更新且更新过程可验证。这一章讲两个具体技巧：增量 diff 怎么做、质量监控看哪些指标。

6.1 用 diff 表做增量更新而不是全量覆盖

全量覆盖简单但浪费，且切换风险高。更稳的做法是每次新数据到来时和旧库做 diff，只更新变化的行。diff 逻辑用 SQL 就能完成，把新数据导入临时表后跑三条语句：新增、变更、删除。变更检测重点看province、city、carrier三个字段，任何一个变了都要更新并记录变更日志，方便回溯“为什么这个号码上个月是移动这个月是联通”。

-- 新增：新表有、旧表没有 INSERT INTO phone_location SELECT n.* FROM phone_location_new n LEFT JOIN phone_location o ON n.prefix7 = o.prefix7 WHERE o.prefix7 IS NULL; -- 变更：前缀相同但归属信息不同 UPDATE phone_location o JOIN phone_location_new n ON o.prefix7 = n.prefix7 SET o.province = n.province, o.city = n.city, o.carrier = n.carrier, o.precision = n.precision, o.updated_at = n.updated_at WHERE o.province <> n.province OR IFNULL(o.city,'') <> IFNULL(n.city,'') OR o.carrier <> n.carrier;

逻辑说明：LEFT JOIN ... IS NULL找新增，JOIN ... WHERE 字段不等找变更。IFNULL处理city为空的比较，避免NULL <> NULL恒为假导致漏更新。删除操作要谨慎，号段回收很少见，一般不做物理删除，只标记deprecated字段，防止误删导致线上查询突然失效。

6.2 质量监控：覆盖率、命中率和异常号段三个指标

更新完得知道数据好不好，我一般盯三个指标。覆盖率：当前在用 3 位号段中有多少在库里有记录，低于 95% 要补数据。命中率：线上查询中 7 位命中的比例，这个比例持续下降说明号段在老化。异常号段：查询返回precision=0的号码按 3 位前缀聚合，如果某个前缀集中出现大量未命中，大概率是新放号段没收录。这三个指标做成日报，比事后用户投诉再排查高效得多。

6.3 一个我常用来验证更新正确性的抽样脚本

每次更新后，我会从新旧两版各抽 500 个号段，人工核对 20 条，再跑一个自动比对脚本看差异分布。差异超过 3% 就暂停切换，先查原因。这个习惯帮我拦下过好几次“数据源把省份字段整体错位”的事故。验证脚本的核心就是对比两版结果并输出差异明细，逻辑简单但必须每次跑，别嫌麻烦。做数据这行，后悔药就是更新前的抽样验证，省这一步迟早要还。希望帮到你。

本文还有配套的精品资源，点击获取