MySQL手机号归属地号段库：索引设计与毫秒级查询优化

简介：面向数据库查询练习与手机号归属地分析场景的MySQL数据集，适合数据库初学者、数据分析人员及需要做号码归属地匹配的开发者使用。压缩包共1个文件，为SQL格式，体积约2.22MB，核心是手机号与省份、城市等归属信息的关联表，导入MySQL后即可通过简单SELECT语句按号码查询归属地，也可结合GROUP BY、JOIN等完成区域分布统计、用户画像预处理和批量匹配任务，省去自行收集与清洗基础数据的步骤。数据覆盖较全，表结构直观，既能作为SQL查询与聚合练习的素材，也能为营销分析、客户服务等业务原型提供参考。目前已有270人学习下载。使用时需注意手机号属于敏感个人信息，应在合法合规前提下访问、加密存储并限制权限，避免泄露。

1. 一个手机号查归属地，不必每次都走外部接口

做注册风控那阵子，判断一个手机号是不是「外地号」，最省事的做法是调第三方接口。但调用量一上来，费用和延迟都不好看，接口一挂，注册链路跟着抖。这份 mysql 号段库对付的就是这件事——把手机号前 7 位到省份、城市、运营商的映射关系落到一张表里，导入一次，之后全是本地查询，毫秒级返回，还没有外部依赖，离线跑批也不受影响。

它适合谁：中小团队的 Java/Python 后端、做数据清洗和用户画像的同学、需要在离线环境里批量补全归属地的场景。不适合要求精确到区县、或者必须反映携号转网实时状态的业务，那种还是得走运营商侧能力。下面按「库长什么样 → 怎么跑起来 → 怎么改」的顺序拆。

2. 库结构拆解：一张号段表撑起全部查询

拿到这类数据包，第一件事不是急着导入，而是先看它的字段规划。号段库的本质是一张对照表，设计好坏直接决定了后面查询是走主键还是走全表扫描，这个差别在百万级调用下就是几十倍的性能差。我这边的习惯是：先定主键，再定冗余字段，最后才考虑物化视图和字典表。

提示：下面示例里的省份城市我用了代称（某省、A 市），你手上的库里存的是真实文本，字段类型和长度一致即可，不影响任何逻辑。

2.1 字段设计：7 位前缀为什么是主角

手机号是 11 位，但归属地信息在前 7 位就基本确定了：前 3 位是号段（运营商 + 业务类型），第 4 到第 7 位是地区分配码。所以整张表的主键只需要 7 位，第 8 到第 11 位是用户序号，跟归属地无关。想清楚这一点，表结构就没什么可纠结的了。

CREATE TABLE `phone_segment` ( `prefix` char(7) NOT NULL COMMENT '号段前7位，如 1380000', `province` varchar(20) NOT NULL DEFAULT '' COMMENT '归属省份', `city` varchar(30) NOT NULL DEFAULT '' COMMENT '归属城市', `isp` tinyint NOT NULL DEFAULT 0 COMMENT '运营商编码：0未知 1/2/3 对应三家', `area_code` char(4) NOT NULL DEFAULT '' COMMENT '长途区号，如 010', `zip_code` char(6) NOT NULL DEFAULT '' COMMENT '邮政编码', `card_type` tinyint NOT NULL DEFAULT 1 COMMENT '1普通卡 2虚拟运营商 3物联网卡', `updated_at` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '行更新时间，供增量同步用', PRIMARY KEY (`prefix`), KEY `idx_prefix6` (`prefix`(6)) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci;

这里有几个刻意的选择。prefix用char(7)而不是varchar(7)，因为号段长度恒定，定长类型在 InnoDB 的聚簇索引里存储更紧凑，页内能塞更多行，同样的 buffer pool 能缓存更多索引页。isp用tinyint存编码而不是直接存「运营商 A」这种字符串，一是省空间，二是后面加字典表可以随时改名不用动主表。

area_code和zip_code不是每个业务都要，但既然是完整的号段库，留着不亏——做发票抬头、物流分单、区域报表的时候经常要用到。card_type这一列很多人会忽略，实际上 170/171/162/165 这类虚拟运营商号段、以及 14 开头的物联网卡，归属地逻辑跟普通卡不完全一样，标注出来能少踩不少坑。

2.2 主键与索引：等值查询为什么比 LIKE 快一个量级

把prefix直接设成主键，意味着 InnoDB 会用它建聚簇索引，数据行就挂在 B+ 树的叶子节点上。一次查询从根走到叶子，拿到主键值的同时就把整行数据带出来了，不需要回表。这是这类对照表最理想的形态。

很多人的第一反应是「加个自增 id 做主键，prefix 上加唯一索引」，理由是「主键要短要递增」。这个说法在写多读少的业务表上成立，但号段表是典型的读多写零：数据导入之后基本不动，查询 QPS 可能上万。用自增 id 的话，每次查询要先在二级索引里找到 id，再回聚簇索引取行，多一次 B+ 树查找，白给的性能损失。

-- 推荐：主键等值，type=const，一次索引查找 EXPLAIN SELECT province, city, isp FROM phone_segment WHERE prefix = '1380000'; -- 次选：前缀 LIKE，只有左侧是常量才能用上索引，type=range EXPLAIN SELECT province, city, isp FROM phone_segment WHERE prefix LIKE '13800%'; -- 反例：字段被函数包裹，索引直接失效，type=ALL EXPLAIN SELECT province, city, isp FROM phone_segment WHERE LEFT(prefix, 6) = '138000';

idx_prefix6这个 6 位前缀索引是我特意加的，用途是降级查询：有些新号段在主表里只有 7 位全量记录，但遇到缺失时可以用 6 位粗查兜底。要注意前缀索引的局限——它不能用于覆盖索引（必须回表），也不能用于ORDER BY和GROUP BY，只能当等值/范围过滤用。知道它能干什么不能干什么，才不会在错误的场景里迷信它。

2.3 数据分层：号段表、字典表、区号表怎么分工

原始数据包往往是一张大宽表，省份城市运营商全塞在一起。直接拿来用没问题，但要做二次开发就不够灵活了。我一般会拆成三层：主表存号段映射，字典表存运营商编码和名称，区号表存省市到区号邮编的对照。查询时用视图拼起来，业务侧看到的还是「一张表」。

CREATE TABLE `isp_dict` ( `isp_id` tinyint NOT NULL, `isp_name` varchar(20) NOT NULL DEFAULT '', PRIMARY KEY (`isp_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; INSERT INTO isp_dict (isp_id, isp_name) VALUES (0, '未知'), (1, '运营商A'), (2, '运营商B'), (3, '运营商C'); CREATE OR REPLACE VIEW `v_phone_segment` AS SELECT s.prefix, s.province, s.city, s.isp, d.isp_name, s.area_code, s.zip_code, s.card_type FROM phone_segment s LEFT JOIN isp_dict d ON d.isp_id = s.isp;

LEFT JOIN而不是INNER JOIN，是为了让isp = 0的未知号段也能查出来，不至于因为字典缺一条就把整行丢掉。视图在 MySQL 里有两种执行算法，MERGE会把条件合并到外层查询、走索引；TEMPTABLE会先物化再过滤，性能差很多。这类简单 JOIN 视图默认走MERGE，但如果你后面在视图里加了GROUP BY或聚合函数，一定记得用EXPLAIN确认一下别退化成物化。

2.4 数据规模与存储估算：为什么它天生适合常驻内存

一份「非常全」的号段库，行数通常在几十万这个量级。按每行 60 到 80 字节估算，聚簇索引本身几十 MB，加上两个二级索引，整体也在百 MB 以内。这个体量意味着它几乎可以完整装进 InnoDB 的 buffer pool，首次预热之后所有查询都是内存操作，磁盘 IO 基本为零。

看到这张表你就能明白，为什么这类库在单机上跑得飞快——数据量小到索引树只有三四层，热数据全在内存里，单次查询的耗时基本就是网络往返加解析的开销，1ms 以内很正常。反过来说，如果你把号段表和百万行用户表做 JOIN，慢的绝对不是号段表这一侧，别搞错优化对象。

3. 跑通链路：从建库导数据到一条 SQL 出结果

结构看完，接下来是把它真正跑起来。这一段我按建库、导入、清洗、回填四步走，每步都给能直接抄的命令。整个流程在一台普通开发机上十分钟内能走完，导入环节是唯一可能卡住的地方，原因后面会讲。

3.1 建库建表与字符集选择

字符集这件事，在这类带中文的数据上翻车概率极高。源文件可能是 GBK 存的，也可能是 UTF-8 无 BOM，导入时不显式指定就会变成一堆问号，而且这种错误不可逆——导进去的乱码再改字符集也救不回来。

-- 建库时就把字符集钉死，别依赖服务端默认值 CREATE DATABASE IF NOT EXISTS phone_geo DEFAULT CHARACTER SET utf8mb4 DEFAULT COLLATE utf8mb4_general_ci; USE phone_geo; SET NAMES utf8mb4; -- 关键：显式声明客户端字符集

排序规则我选utf8mb4_general_ci而不是 8.0 默认的utf8mb4_0900_ai_ci。原因是号段表做的是纯粹的等值匹配，排序规则的差别对查询结果零影响，但general_ci在 5.7 和 8.0 上都能用，将来把库从低版本迁到高版本不会因为排序规则不兼容报错。这种小便宜，吃过一次亏就会记一辈子。

3.2 导入数据：LOAD DATA INFILE 与 source 两条路

导入有两种方式，选哪个取决于你手上是 SQL 文件还是 CSV/TXT。如果是.sql文件，直接命令行灌进去最快：

# 大文件导入时加上这几个参数，能明显快一截 mysql -u root -p \ --default-character-set=utf8mb4 \ --max_allowed_packet=256M \ phone_geo < /data/phone_segment.sql

如果是 CSV，用LOAD DATA比逐条 INSERT 快一个数量级：

LOAD DATA LOCAL INFILE '/data/phone_segment.csv' INTO TABLE phone_segment CHARACTER SET utf8mb4 FIELDS TERMINATED BY ',' OPTIONALLY ENCLOSED BY '"' LINES TERMINATED BY '\n' IGNORE 1 LINES (prefix, province, city, isp, area_code, zip_code) SET card_type = 1; -- 源文件没这一列时给默认值

CHARACTER SET utf8mb4这一句必须写，它告诉 MySQL 按什么编码去解析文件，不写就按表的默认字符集猜，猜错就是乱码。OPTIONALLY ENCLOSED BY '"'用来处理带引号的字段，有些导出工具会把所有字段都裹上双引号。IGNORE 1 LINES跳过表头，如果你的 CSV 没有表头就删掉这行。

LOCAL关键字很容易出问题：它要求客户端和服务器两端都开启本地加载。服务端是local_infile=ON，命令行客户端要加--local-infile=1。少了任何一个，报错信息都是The used command is not allowed with this MySQL version，看起来像版本问题，其实是权限开关。服务器上非 LOCAL 的LOAD DATA INFILE还受secure_file_priv限制，路径必须落在那个人指定的目录里。

3.3 号码归一化：把 +86、空格、短横线先挡在门外

真实业务里的手机号，几乎不可能是干净的 11 位数字。前面带+86的、中间有空格短横线的、用户手抖多打一位的，什么都有。这些脏数据如果不处理，LEFT(mobile, 7)取到的就是+86 138这种鬼东西，查出来当然是空。

-- MySQL 8.0 写法：正则剔除所有非数字字符，再处理 86 国家码 SELECT CASE WHEN CHAR_LENGTH(digits) = 13 AND digits LIKE '86%' THEN SUBSTRING(digits, 3, 11) -- 去掉 86 前缀，取 11 位 WHEN CHAR_LENGTH(digits) = 15 AND digits LIKE '0086%' THEN SUBSTRING(digits, 5, 11) -- 处理 0086 前缀 ELSE digits END AS msisdn FROM ( SELECT REGEXP_REPLACE('+86 138-0000-1234', '[^0-9]', '') AS digits ) t;

逻辑分三层：REGEXP_REPLACE先把+、空格、短横线全部干掉，只留数字；然后判断长度，13 位且以 86 开头就截掉前两位，15 位且以 0086 开头就截掉前四位；剩下的原样返回。CHAR_LENGTH而不是LENGTH，因为后面还要做位数校验，用字符数更直观。MySQL 5.7 没有REGEXP_REPLACE，得用嵌套REPLACE一层层剥，丑但能用：

-- 5.7 兼容写法：链式 REPLACE SELECT REPLACE(REPLACE(REPLACE(REPLACE('+86 138-0000-1234', '+', ''), ' ', ''), '-', ''), '86', '') AS digits;

链式写法有个隐患：如果号码中间恰好出现86这两个数字，会被误删。所以 5.7 上更稳的做法是把清洗放到应用层，SQL 只负责最后的前缀匹配。让数据库干它擅长的事，这种判断力比多写几行 SQL 值钱。

3.4 与业务表对接：一条 UPDATE JOIN 批量回填

单条查询跑通之后，最常见的需求是给存量用户表补归属地。这里用UPDATE ... JOIN一条搞定：

UPDATE user_profile u JOIN phone_segment p ON p.prefix = LEFT(u.mobile, 7) SET u.province = p.province, u.city = p.city, u.isp = p.isp WHERE u.mobile REGEXP '^1[3-9][0-9]{9}$' -- 只处理合法 11 位号 AND (u.province IS NULL OR u.province = ''); -- 只补空值，不覆盖已有数据

这里的LEFT(u.mobile, 7)是作用在 JOIN 条件上的函数，但它包裹的是驱动表的列，被驱动表（号段表）的prefix是裸列，所以号段表这一侧照样走主键等值查找，效率没问题。真正要小心的是驱动表——用户表如果几百万行，这一条 UPDATE 会开一个大事务，锁住大量行，线上跑就是事故。

我的做法是分批，按主键区间切片，每批几千行，批间 sleep 一下：

-- 分批回填，脚本里循环推进 id 区间 UPDATE user_profile u JOIN phone_segment p ON p.prefix = LEFT(u.mobile, 7) SET u.province = p.province, u.city = p.city, u.isp = p.isp WHERE u.id > 0 AND u.id <= 5000 AND (u.province IS NULL OR u.province = '');

批次大小取决于行宽和机器配置，5000 是个保守值。监控SHOW ENGINE INNODB STATUS里的锁等待，一旦出现堆积就立刻调小。这种批量任务放在业务低峰期跑，是基本礼貌。

4. 性能优化：把单次查询压到 1ms 以内的几种做法

前面说过，号段表体量小，主键等值查询本来就不慢。但真实系统里，慢往往不是因为号段表本身，而是写法不对或者调用方式不对。这一章讲三个层面的优化：SQL 怎么写、缓存怎么加、批量怎么批。

4.1 三种前缀匹配写法的执行计划对比

同样是查归属地，写法差别能拉出一个数量级的性能差。我拿一个真实场景对比过三种写法，结果如下：

第三种写法最容易犯：直觉上觉得「手机号以号段开头」就该写成mobile LIKE prefix%，但在 SQL 里这意味着遍历号段表的每一行去拼字符串比较，几十万行全扫一遍。正确姿势永远是让号段字段在等号左边。

-- 正确：号段字段裸列在左，函数只包参数 SELECT province, city, isp, area_code FROM phone_segment WHERE prefix = LEFT(?, 7);

LEFT(?, 7)里的?是常量参数，MySQL 在优化阶段就会把它算出来，等价于写死一个字符串。所以别担心「函数会导致索引失效」——失效的前提是函数包在字段上，包在参数上没事。这个区别值得记牢。

4.2 缓存层：Redis 预热与 MySQL MEMORY 表

单机 MySQL 撑几千 QPS 没问题，但如果业务是高频调用（比如每次请求都要判归属地），加一层缓存更稳。两种常见做法：Redis 预热，或者 MySQL 的 MEMORY 引擎表。

import pymysql import redis r = redis.Redis(host="127.0.0.1", port=6379, decode_responses=True) KEY_PREFIX = "ph:seg:" def warm_up(): """把号段全量灌进 Redis，启动时跑一次""" conn = pymysql.connect(host="127.0.0.1", user="app", password="***", database="phone_geo", charset="utf8mb4") cur = conn.cursor() cur.execute("SELECT prefix, province, city, isp FROM phone_segment") pipe = r.pipeline() # 管道批量写，避免逐条往返 count = 0 for prefix, province, city, isp in cur.fetchall(): pipe.hset(KEY_PREFIX + prefix, mapping={ "p": province, "c": city, "i": isp}) count += 1 if count % 5000 == 0: # 每 5000 条提交一次，控制内存峰值 pipe.execute() pipe.execute() cur.close() conn.close() print(f"warmed {count} segments")

用HSET存单个 hash 而不是把整行序列化成字符串，好处是后面要加字段（比如补上area_code）不用改结构，直接多塞一个 field。键名加ph:seg:前缀是为了在共享 Redis 里跟其他业务隔开，这个习惯能救命——我见过太多人把裸键名扔进共享实例，最后跟别人的user:1撞得莫名其妙。

MEMORY 引擎表是另一条路，语法上就是把ENGINE=InnoDB换成ENGINE=MEMORY：

CREATE TABLE phone_segment_mem ( prefix char(7) NOT NULL, province varchar(20) NOT NULL DEFAULT '', city varchar(30) NOT NULL DEFAULT '', isp tinyint NOT NULL DEFAULT 0, PRIMARY KEY (prefix) ) ENGINE=MEMORY DEFAULT CHARSET=utf8mb4; INSERT INTO phone_segment_mem SELECT prefix, province, city, isp FROM phone_segment;

MEMORY 表的数据全在内存里，查询比 InnoDB 还快一点，但代价很明确：服务重启数据全丢，而且不支持TEXT/BLOB类型，单表大小受max_heap_table_size限制。所以它只适合当缓存用，原始数据必须留在 InnoDB 表里，重启后重新灌一遍。别把它当持久化方案，那是给自己埋雷。

4.3 批量查询：IN 列表分批与去重

批量补归属地的场景，最忌讳一条一条查。正确做法是把待查号码的前缀去重后一次性IN进去，但IN列表也不能无限长——超过几百上千个参数，解析开销和网络包大小都会拖慢查询。

def batch_lookup(conn, mobiles, batch_size=500): """批量查归属地，返回 {prefix: (province, city, isp)}""" # 只取合法号码的前 7 位，去重后排序，减少 IN 列表长度 segs = sorted({m[-11:-4] for m in mobiles if len(m) >= 11 and m[-11:].isdigit()}) result = {} cur = conn.cursor() for i in range(0, len(segs), batch_size): chunk = segs[i:i + batch_size] placeholders = ",".join(["%s"] * len(chunk)) sql = ("SELECT prefix, province, city, isp FROM phone_segment " f"WHERE prefix IN ({placeholders})") cur.execute(sql, chunk) for prefix, province, city, isp in cur.fetchall(): result[prefix] = (province, city, isp) cur.close() return result

这里m[-11:-4]直接切字符串拿前 7 位，比LEFT()函数快，因为不涉及函数调用。前提是调用前已经做过归一化，号码是干净的 11 位数字串。sorted(set(...))既去重又让参数顺序稳定，对 MySQL 的查询缓存（5.7 有，8.0 已移除）和 Prepared Statement 复用都友好。批次定 500 是经验值，实际可以压测调，但别超过 1000，收益递减还容易撞上max_allowed_packet。

4.4 号段增量更新：upsert 而不是 truncate 重灌

号段数据不是一成不变的，运营商隔一阵子就会放新号段出来。很多人的更新方式是TRUNCATE TABLE再全量导入——这在生产上是灾难：清表那一瞬间所有查询都查不到数据，业务侧直接报「未知归属地」，用户投诉就来了。

正确做法是走临时表加 upsert，只动有变化的行：

-- 1. 新数据先落到结构相同的临时表 CREATE TABLE phone_segment_stage LIKE phone_segment; LOAD DATA LOCAL INFILE '/data/phone_segment_new.csv' INTO TABLE phone_segment_stage CHARACTER SET utf8mb4 FIELDS TERMINATED BY ',' OPTIONALLY ENCLOSED BY '"' LINES TERMINATED BY '\n' IGNORE 1 LINES (prefix, province, city, isp, area_code, zip_code); -- 2. 一次性合并，存在则更新，不存在则插入 INSERT INTO phone_segment (prefix, province, city, isp, area_code, zip_code) SELECT prefix, province, city, isp, area_code, zip_code FROM phone_segment_stage ON DUPLICATE KEY UPDATE province = VALUES(province), city = VALUES(city), isp = VALUES(isp), area_code = VALUES(area_code), zip_code = VALUES(zip_code);

ON DUPLICATE KEY UPDATE依赖主键冲突触发，所以prefix做主键在这里正好派上用场。整个过程表一直可读可查，只有合并那一小段时间有行锁，影响面远小于清表重灌。合并完再核一下行数差异，确认新数据确实进来了。

注意：MySQL 8.0.20 起VALUES()函数被标记为废弃，官方推荐用行别名。新项目里可以写成INSERT INTO ... SELECT ... FROM phone_segment_stage AS new ON DUPLICATE KEY UPDATE province = new.province，老版本继续用VALUES()也没问题，只是会有废弃警告。

5. 排查手册：归属地对不上的 5 个常见问题

这套库跑起来不难，难的是跑起来之后发现结果不对，却不知道从哪查起。下面五条是我在实际项目里真遇到过的，按「现象 → 原因 → 解决」写，遇到同类问题可以直接对照。

5.1 号码格式引发的空结果

现象：某些用户明明填了手机号，归属地字段就是空的，但把号码复制出来手工查又能查到。

原因：前端传上来的号码带+86或者空格，LEFT(mobile, 7)取到的是+86 138这种非数字串，跟号段表里任何prefix都对不上，JOIN自然没结果。另一种情况是号码长度不对，比如 10 位或者 12 位，前 7 位取出来看着像号段，实际是错位的。

解决：在入库前统一归一化，把清洗逻辑前置到写入链路，而不是等查询时再补救。校验用正则卡住：^1[3-9][0-9]{9}$。已经进了库的脏数据，用 3.3 节的REGEXP_REPLACE方案跑一次批量订正，订正前先SELECT出来抽样确认，别直接UPDATE。

现象：大部分号码正常，但 170、171 开头的号段归属地一律是「未知」。

原因：虚拟运营商号段在主表里缺失，或者源数据包里这几个号段是空值。这类号码的号段分配跟基础运营商不同，很多早期版本的号段库根本没收录。

解决：先用SELECT * FROM phone_segment WHERE prefix LIKE '170%'确认是真的缺失还是 value 为空。真缺失就得补数据源；如果只是空值，用 6 位前缀索引降级查一次粗粒度归属地，再查不到就老老实实标记为未知，别硬猜。

5.2 数据与索引引发的错配和慢查询

现象：上线一段时间后，DBA 报警说这条查询 CPU 打满，慢日志里全是号段查询。

原因：几乎可以肯定是写成了WHERE ? LIKE CONCAT(prefix, '%')或者WHERE LEFT('13800001234', 7) = prefix这种把字段放在函数里的形式。执行计划type=ALL，几十万行全表扫，QPS 一上来就顶不住。

解决：改成WHERE prefix = LEFT(?, 7)，字段裸列在等号左边。改完立刻EXPLAIN确认type变成const。如果业务代码里这种写法散落多处，加一层 DAO 把查询收口，别指望每个调用方都记得规则。

现象：导入之后查出来省份是一堆问号，或者中文变成????。

原因：LOAD DATA时没指定CHARACTER SET，MySQL 按表的默认字符集去解析源文件，源文件是 GBK 就必然乱码。这个错误在导入那一刻就固化了，后面的查询怎么改都救不回来。

解决：TRUNCATE之后重新导入，这次显式写CHARACTER SET utf8mb4，并且确认源文件本身确实是 UTF-8。导入前拿file -i看一眼编码，比导完再排查省事得多。

现象：同一条号段查出来两条记录，或者昨天还查得到今天突然查不到了，归属地还会「飘」。

原因：多份数据源合并时没去重，主键没设成prefix而是自增 id，导致同一号段插入了两行。JOIN的时候匹配到哪一行完全看执行计划，结果就是不确定的。

解决：先把主键改成prefix，改之前用SELECT prefix, COUNT(*) FROM phone_segment GROUP BY prefix HAVING COUNT(*) > 1找出重复行，按updated_at保留最新的一条。改完主键之后，后续所有更新都必须走 4.4 节的 upsert，INSERT撞主键会直接报错，等于免费加了一道数据质量闸门。

6. 二次开发：把号段表封装成能上线的查询服务

直接让业务代码写 SQL 查号段表，短期能跑，长期一定乱——有人忘了归一化，有人用了LIKE，有人把整表SELECT出来在内存里遍历。稳妥的做法是包一个薄薄的服务层，对外只暴露「传手机号，返回归属地」这一个语义。

class PhoneGeoService: def __init__(self, conn, cache=None): self.conn = conn self.cache = cache # 可选 Redis 客户端 self._local = {} # 进程内 LRU，挡住最热的那批号段 def lookup(self, mobile: str) -> dict: msisdn = self._normalize(mobile) if not msisdn: return {"province": "", "city": "", "isp": 0, "hit": False} seg = msisdn[:7] if seg in self._local: # 一级：进程内缓存 return {**self._local[seg], "hit": True} row = self._query(seg) if row is None and self.cache is not None: # 二级：Redis row = self.cache.hgetall(f"ph:seg:{seg}") or None if row is None: # 三级：降级到 6 位粗查 row = self._query(seg[:6], exact=False) if row: self._local[seg] = row return {**row, "hit": True} return {"province": "", "city": "", "isp": 0, "hit": False} @staticmethod def _normalize(mobile: str): digits = "".join(ch for ch in mobile if ch.isdigit()) if len(digits) == 13 and digits.startswith("86"): digits = digits[2:] return digits if len(digits) == 11 and digits[0] == "1" else ""

三级缓存的设计逻辑是：进程内字典最快但容量有限，只装最热的号段；Redis 装全量，跨进程共享；MySQL 兜底并支持 6 位降级。hit字段返回给调用方，是为了让上游能区分「查到了但归属地就是空」和「压根没查到」，这两种情况在风控策略里处理方式不一样。_normalize里digits[0] == "1"这个校验很关键，很多脏数据能过长度检查但首位不是 1，放进去纯属污染缓存。

更新流程我给自己定了三道闸门，每次换数据都必须走完。第一道是前缀唯一性校验，GROUP BY prefix HAVING COUNT(*) > 1必须返回空；第二道是抽样比对，从新老库里各抽 1000 个号段，逐条 diff 省市运营商，差异率超过阈值就人工看；第三道是灰度，先只更新一台从库或者一个缓存分片，观察 24 小时的查询命中率和未知率，没问题再全量推。

这三道闸门听起来繁琐，但都是被坑出来的。有一回我图省事直接全量覆盖，结果新数据包里有一批号段的运营商编码从 1 变成了 0，当天风控模型的地域特征全成了空值，第二天才被发现。从那以后我每次更新号段库，都强制先跑唯一性校验和抽样比对，确认没问题才切流量。希望帮到你。

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