简介：面向开发人员与数据分析者的全国行政区域代码数据库，覆盖县、乡镇、街道及居委会等各级区划，可用于地图服务、人口统计、金融服务定位与政策分析等场景。压缩包共3个SQL文件，约9.08MB，分别承载城镇级区划、县级区划与银行区域代码数据，字段涵盖名称、行政代码、所属省市及机构信息，便于直接导入数据库查询与二次开发。已有967人学习下载，适合需要快速获取权威区划底表、搭建地理信息相关应用的中级开发者参考使用。
1. 全国行政区域代码近 70 万条：一份能直接落库的地址主数据
做用户地址、网点归属、配送范围、风控归属地这几类需求时，最容易被低估的不是接口，而是底表。全国行政区域代码这份资源，覆盖到县、乡镇、街道、居委会四级，接近 70 万条记录，本质是一份可以直接灌进数据库的地址主数据。它解决的是“地址怎么写都行、统计口径对不上、层级关系理不清”的老问题。适合做 CRM、物流分单、银行网点区域归属、政务类表单联动的从业者，尤其适合那些被“省市区三级够用”坑过一次的人。
2. 先看清数据骨架：四级层级与编码规则怎么读
拿到一份近 70 万条的行政区域代码表，第一反应不该是建表导入，而是先搞清楚它的层级结构和编码逻辑。层级读错了，后面所有关联查询都是错的；编码规则没吃透，做区域聚合时会出现“同一个市被拆成两半”的玄学问题。这一章先把数据骨架拆开，再谈怎么落到库里。
2.1 四级层级：省、县乡镇、街道、居委会的从属关系
这份数据的核心价值在于它把行政层级压到了最细的居委会一级。常见的行政区划代码只到区县，而实际业务里，街道和居委会才是地址匹配的最后一公里。层级关系大致是这样的：省级是顶层，往下是地市，再往下是区县，然后是乡镇/街道，最末是居委会/村委会。但要注意，不同地区的层级命名并不统一，有的地方叫“街道”，有的叫“镇”，有的地方居委会下面还有“社区”。
从数据组织的角度看，每一级都靠一个父级编码字段挂到上一级，形成一棵树。真正做关联时，不能假设“层级深度固定为五层”，因为直辖市、省直管县、开发区这类特殊情况会让层级跳变。我一般会先跑一遍父级编码的空值和孤儿记录检查，确认这棵树的完整性，再决定用递归查询还是预计算路径字段。
-- 检查层级完整性：找出父级编码指向不存在记录的孤儿节点 SELECT child.code, child.name, child.parent_code FROM region_code child LEFT JOIN region_code parent ON child.parent_code = parent.code WHERE child.parent_code IS NOT NULL AND child.parent_code <> '' AND parent.code IS NULL;这段 SQL 的逻辑很直接：以自身表做左连接，凡是父级编码非空但连接不上父级记录的，就是孤儿节点。参数上唯一要改的是表名和字段名，字段命名各家不一样，常见的是 code、name、parent_code 三件套。跑出来如果孤儿记录数量在几十条以内，通常是数据本身的边界情况，可以人工核对；如果上千条，说明这份数据的父级字段口径有问题，得先清洗再入库。
2.2 编码规则：12 位行政区划码与统计用区划码的区别
行政区域代码最容易翻车的地方，是把“行政区划代码”和“统计用区划代码”混为一谈。前者一般是 6 位起步的民政口径编码，后者是统计部门用的 12 位编码，两者在街道、居委会这一级差异明显。这份近 70 万条的数据，细到居委会一级，大概率用的是统计用区划码体系，也就是 12 位结构：前 6 位对应县及以上，中间 3 位是乡镇/街道，后 3 位是居委会/村委会。
理解这个结构的意义在于：你可以用字符串截取直接做层级聚合，不必每次都递归查父级。比如取前 6 位就是区县级聚合，取前 9 位就是乡镇街道级聚合。这种“编码即层级”的设计，在数据量接近 70 万条时，比递归查询快一个数量级。
import pandas as pd df = pd.read_csv("region_code.csv", dtype=str) # 按编码前缀做层级聚合，验证 12 位结构是否成立 df["province_code"] = df["code"].str[:2] df["city_code"] = df["code"].str[:4] df["county_code"] = df["code"].str[:6] df["town_code"] = df["code"].str[:9] # 统计每一级的唯一值数量，和常识量级做比对 for level in ["province_code", "city_code", "county_code", "town_code"]: print(level, df[level].nunique())这段代码的关键在dtype=str，编码必须按字符串读，按整数读会把前导零吃掉，010000变成10000，后面所有截取全错。参数上，str[:2]、str[:4]这些切片位置要按你手上数据的实际编码长度调整，如果发现某份数据是 9 位或 12 位混排，先统一长度再聚合。跑出来的省级唯一值应该在 30 多个，市级 300 多个，县级 2800 多个，乡镇街道 4 万上下，居委会级接近 70 万，量级对不上就说明编码结构不是你以为的那样。
提示：编码字段一律用字符串类型存储，数据库建表时用 VARCHAR 而不是 INT，这是后面所有查询不出错的前提。
3. 落库与查询：把 70 万条数据用起来的三种姿势
数据骨架看清之后，接下来是真正落地。近 70 万条记录不算大数据，但也绝不是一张小表，直接全量加载进内存做匹配、或者不加索引就上线查询，都会在生产环境里翻车。这一章讲三种实际会用到的落地方式：建表与索引、地址模糊匹配、以及按业务口径做区域聚合。
3.1 建表与索引：让层级查询跑在毫秒级
建表时最容易被忽略的是索引设计。很多人只给主键编码建了索引，结果按名称模糊查地址时全表扫描，70 万条扫一遍就是几百毫秒起步，并发一上来直接拖垮。合理的做法是给编码、父级编码、名称三个字段分别建索引，编码和父级编码用普通 B-Tree 索引，名称如果要做前缀匹配，可以考虑前缀索引。
CREATE TABLE region_code ( code VARCHAR(12) NOT NULL COMMENT '区划编码', name VARCHAR(64) NOT NULL COMMENT '区域名称', parent_code VARCHAR(12) DEFAULT NULL COMMENT '父级编码', level TINYINT NOT NULL COMMENT '层级 1省 2市 3县 4乡镇街道 5居委会', PRIMARY KEY (code), KEY idx_parent (parent_code), KEY idx_name (name(16)), KEY idx_level (level) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;建表语句里几个参数值得说清楚。code用VARCHAR(12)而不是定长，是因为不同来源的数据编码长度可能不一致，定长会截断。idx_name用了前缀索引name(16)，因为区域名称普遍不长，前缀 16 个字符足够区分大部分记录，同时索引体积小很多。level字段是冗余设计，用空间换查询便利，做“只查街道级”这类过滤时不用再靠编码长度推断。导入时用批量INSERT或LOAD DATA，单条插入 70 万次会慢到怀疑人生。
3.2 地址模糊匹配：从一段文本反查居委会编码
实际业务里拿到的往往不是干净的编码，而是一段用户填的地址文本，比如“某省某市某区某街道某社区”。要从这段文本反查出居委会编码，靠精确匹配不行，得做分词加逐级收敛。常见做法是先按省名匹配到省级，再在省级范围内匹配市名，逐级往下缩小范围，最后一级用模糊匹配兜底。
def match_region(address: str, df: pd.DataFrame) -> str: """逐级收敛匹配，返回最末级匹配到的编码""" current = df for level in [1, 2, 3, 4, 5]: subset = current[current["level"] == level] hit = subset[subset["name"].apply(lambda x: x in address)] if hit.empty: break # 取名称最长的匹配，避免"某县"误匹配到"某县某镇" best = hit.loc[hit["name"].str.len().idxmax()] current = df[df["parent_code"] == best["code"]] matched = best["code"] return matched if "matched" in dir() else ""这段逻辑的核心是“逐级收敛 + 最长名称优先”。参数上，level的取值要和你数据里的层级定义对齐；x in address是子串判断，简单但有效，如果地址文本里有多义地名，可以换成更严格的正则或分词库。要注意的是，这种匹配对地址书写规范度有要求，用户把“街道”写成“街办”、把“社区”省略掉的情况很常见，所以实际用的时候一般会在每一级匹配失败时保留上一级结果，而不是直接返回空。
3.3 区域聚合：按业务口径统计网点与用户归属
银行网点归属、配送范围划分这类需求，本质是按行政区域做聚合统计。有了 12 位编码，聚合可以做得非常灵活：按前 6 位聚合就是区县口径，按前 9 位就是街道口径。难点不在聚合本身，而在口径统一——同一个网点，业务部门按区县报，运营按街道报，两边数字对不上，最后查下来是编码版本不一致。
-- 按街道口径统计网点数量，编码取前 9 位 SELECT LEFT(a.region_code, 9) AS town_code, r.name AS town_name, COUNT(*) AS branch_count FROM bank_branch a JOIN region_code r ON LEFT(a.region_code, 9) = r.code WHERE r.level = 4 GROUP BY LEFT(a.region_code, 9), r.name ORDER BY branch_count DESC;这条查询的关键是LEFT(a.region_code, 9)和r.level = 4的配合，前者把网点编码截到街道级，后者确保关联到的是街道记录而不是同名其他层级。参数上，如果业务口径是区县，把 9 改成 6、level 改成 3 即可。实际踩过的坑是：网点表里的编码可能是旧版区划码，而区域表是新版，直接 JOIN 会丢记录，稳妥做法是先做一次编码版本映射，或者用名称做二次校验。
4. 避坑与排查：这份数据最容易翻车的五个地方
近 70 万条的数据，看着规整，实际用起来问题不少。下面五条是我和身边同行踩过的真实坑，按“现象 → 原因 → 解决”整理，照着排查能省不少时间。
4.1 编码前导零丢失导致层级全错
现象：按编码前缀聚合，省级数量对不上，某些省份凭空消失。原因：编码被当成整数读入或存成 INT 类型，010000变成10000，前缀截取全乱。解决：从读取到建表到查询，编码全程用字符串类型，CSV 读取加dtype=str，数据库用 VARCHAR，接口传参也别转数字。
4.2 同名区域导致匹配串级
现象：地址匹配结果落到隔壁市的同名区县，或者居委会匹配到了另一个街道的同名社区。原因：只按名称匹配，没有利用父级编码约束范围。解决：严格逐级收敛，每一级都在上一级匹配结果的子集里找，绝不跨级全局搜名称；同时对名称做最长优先，避免短名误命中。
4.3 层级深度不固定引发递归死循环
现象：用递归查询展开层级时，某些分支无限循环或报错。原因：数据里存在父级编码指向自身、或两个节点互为父子的脏数据。解决：入库前跑一遍自引用和环检测，递归查询加深度上限保护，超过 6 层直接截断并记录异常编码。
4.4 区划调整后新旧编码混用
现象：统计报表里同一个地区出现两条记录，数字被拆开。原因：行政区划调整后，旧编码未下线，新编码已启用，业务表里两种编码并存。解决：维护一张编码版本映射表，查询时统一映射到当前版本；对历史数据保留版本字段，报表按版本口径出数。
4.5 全表模糊查询拖垮数据库
现象：地址搜索接口偶发超时，慢查询日志里全是LIKE '%xx%'。原因：名称字段没有可用索引，前置通配符让索引失效。解决：改成前缀匹配LIKE 'xx%'走索引，或者引入独立的搜索引擎做地址检索，数据库只承担精确编码查询。
注意：以上五条里，前导零和同名匹配是最常见的两个，新接入这份数据时建议先写两个校验脚本跑一遍，比上线后排查便宜得多。
5. 进阶用法：用编码前缀做区域树缓存与增量更新
把这份数据用顺之后，真正拉开效率差距的是两件事：一是把层级树预计算成缓存，二是处理区划调整带来的增量更新。前者解决查询性能，后者解决数据新鲜度，两个都做到位，这份近 70 万条的主数据才算真正用活。
先讲缓存。既然 12 位编码本身就是层级路径，那就可以在入库时预计算一个path字段，把从省到当前节点的名称用分隔符拼起来，比如“某省/某市/某区/某街道/某社区”。这样前端做级联选择、后端做地址展示时，一次查询就能拿到完整路径，不用递归。预计算的代价是存储多一列，但换来的是查询从递归变成单表扫描，在 70 万条量级下差别很明显。
def build_path(df: pd.DataFrame) -> pd.DataFrame: """基于 parent_code 预计算完整路径，一次遍历建映射""" name_map = dict(zip(df["code"], df["name"])) parent_map = dict(zip(df["code"], df["parent_code"])) def path_of(code): parts, cur, depth = [], code, 0 while cur and depth < 6: # 深度上限防脏数据死循环 parts.append(name_map.get(cur, "")) cur = parent_map.get(cur) depth += 1 return "/".join(reversed(parts)) df["path"] = df["code"].apply(path_of) return df这段代码用两个字典做 O(1) 查找，避免了对 DataFrame 的反复过滤，70 万条跑下来通常在十几秒量级。depth < 6是保护性参数，正常层级不会超过 5 层，超过就说明数据有问题。path字段建好后，前端级联组件可以直接按路径前缀过滤，后端做地址补全也能一次命中。
再讲增量更新。行政区划不是静态的，每年都有乡镇撤并、社区调整。全量重灌 70 万条成本不低，更稳的做法是按编码做差异比对：新数据导入临时表，和主表做code的全外连接，新增的插入、消失的标记下线而不是物理删除、名称变化的更新。这样既保留了历史可追溯性，又不会因为一次调整把关联业务表打乱。
| 变更类型 | 判定条件 | 处理方式 |
|---|---|---|
| 新增 | 临时表有、主表无 | 插入，标记生效日期 |
| 下线 | 主表有、临时表无 | 标记失效，不物理删除 |
| 改名 | 编码相同、名称不同 | 更新名称，保留旧名到历史表 |
| 父级变更 | 编码相同、parent_code 不同 | 更新父级，重算 path |
这张表是我一般会固化成脚本的比对逻辑，跑完输出一份变更清单，人工确认后再落库。血泪经验是：千万别直接TRUNCATE再全量灌，一旦新数据有问题，连回滚的后悔药都没有。从那以后我每次更新这类主数据，都强制走一遍“临时表 + 差异比对 + 人工确认”的流程，慢是慢一点，但睡得着觉。希望帮到你。
本文还有配套的精品资源，点击获取
