简介：面向政务信息化、地址库建设与数据分析场景整理的五级行政区域数据资源，覆盖省、地、县、乡、村五个层级，包含行政区名称与对应区域代码，可用于地址标准化、区域匹配、下拉联动及统计口径对照等开发与研究工作，适合后端开发、数据工程及GIS相关从业者使用。压缩包共3个文件，以2个SQL脚本和1个CSV数据表为主，SQL文件便于直接导入数据库建表与批量写入，CSV则方便在表格工具或程序中快速查阅与二次处理，整体约18.8MB。数据为2023年3月更新版本，层级划分涵盖自治区、自治州、旗、苏木、行政村与社区等细分类型，结构完整、颗粒度细。目前已有5021人学习下载，可作为区域基础数据底表，减少逐级收集与清洗成本，并为地址库维护和区域编码校验提供参考。
1. 五级行政区域数据库：一张“地址的族谱”到底长什么样
填过收货地址的人都遇到过那种下拉框：先选省，再选市，再选区县，有的还要选街道和社区。你有没有想过，这四级五级的下拉选项，背后到底是从哪来的？答案就是一份五级行政区域数据库——它把全国从省级一路拆到社区/村级，用一张表把“谁归谁管”的层级关系固定下来。
通俗地说，它像一张地址的族谱：省是老祖宗，市是儿子，区县是孙子，街道是曾孙，社区是玄孙，每一层都记着上一层的编号。搞懂它，你才知道为什么地址下拉框能联动、为什么统计报表能按区域汇总、为什么同一个地名在不同年份可能“换了爹”。这份资源提供的正是这样一套带 SQL 文件的完整表结构，值得先弄明白它是什么。
2. 为什么地址不能只存一串文字：层级编码存在的理由
2.1 从“北京市朝阳区”这串字说起
如果数据库里只存“北京市朝阳区某某街道”这样一整串文字，看起来省事，实际处处是坑。同一个地方，有人写“北京朝阳区”，有人写“北京市朝阳区”，还有人写“朝阳区（北京）”，机器根本认不出这是同一个地方。更麻烦的是统计：你想算“朝阳区有多少条记录”，就得做字符串模糊匹配，慢且容易错。
五级行政区域数据库换了个思路：给每个区域一个唯一编码，再记录它的上级编码。地址不再是一串自由文字，而是一组有层级关系的编号。打个比方，这就像给每个家庭成员发一个身份证号，同时在家谱上写明“我爸是谁”，查关系时顺着编号往上找就行，不用猜字面。
这种设计带来的直接好处是：下拉框联动只需按上级编码过滤；按省汇总只需匹配编码前缀；地名改了，编码不变，历史数据不会断链。
2.2 五级到底指哪五级
“五级”不是随便定的，它对应的是实际管理中的层级拆分。通常从高到低是：省级（省、自治区、直辖市）、地级（市、地区、州）、县级（区、县、县级市）、乡级（街道、镇、乡）、村级（社区、村）。前三级大家填快递时都见过，后两级在人口登记、网格管理、疫情排查这类场景里才会用到。
提示：不同来源对层级的叫法略有差异，但“省—市—县—乡—村”这条主线是通用的。看一份数据是否完整，先数它有没有这五层，再看每层是否有稳定的编码。
为什么非要拆到村级？因为很多业务需要“最后一公里”的精度：某个社区的服务点覆盖哪些小区、某个村的户籍人口怎么统计。只到区县，颗粒度太粗；拆到村，才能落到具体网格。这也是这份资源强调“五级”而不是“三级”的价值所在。
2.3 编码里藏着的规则
行政区域编码不是随机数字，它有固定位数和分段含义。以常见的六位县级编码为例，前两位代表省级，中间两位代表地级，后两位代表县级。比如某个编码的前两位固定对应某个省，那么所有以这两位开头的区域都属于这个省。这种前缀即归属的设计，让“按省查询”变成一次简单的前缀匹配，而不需要递归往上找。
到了乡级和村级，编码位数会继续延长，规则类似：前面一段继承上级，后面新增一段标识自己。理解这一点，你就能明白为什么数据库里既要存“编码”，又要存“上级编码”——编码本身已经隐含了层级，上级编码则是为了方便直接关联，避免每次都做字符串截取。
3. 一份行政区域表里到底有什么：字段与 SQL 文件的作用
3.1 核心字段逐个看
一份典型的五级行政区域表，字段不会太多，但每个都有明确用途。下面用一段建表语句示意结构（字段名可按实际调整，重点是含义）：
CREATE TABLE region ( code VARCHAR(12) NOT NULL, -- 区域编码，层级越高位数越短 name VARCHAR(64) NOT NULL, -- 区域名称，如“某区”“某街道” level TINYINT NOT NULL, -- 层级：1省 2市 3县 4乡 5村 parent_code VARCHAR(12) NOT NULL, -- 上级区域编码，顶级为空或固定值 PRIMARY KEY (code) );code是主键，保证每个区域唯一；name是展示用的名称；level让你能快速筛出“只要省级”或“只要村级”；parent_code是联动的关键，下拉框选完省，就用省的 code 去查parent_code等于它的市。代码后的说明对应每个字段的业务含义，改字段名时别丢掉这层语义。
注意：编码位数在不同数据源里可能不一致，有的用 6 位到县级、12 位到村级，有的统一长度。拿到数据先看编码长度分布，再决定字段类型，别一上来就定死
CHAR(6)。
3.2 SQL 文件解决的是“落地”问题
光有概念不够，实际用的时候你得把数据灌进数据库。这份资源附带 SQL 文件，作用就是把表结构和数据一次性准备好：建表语句负责定义字段，插入语句负责把成千上万条区域记录写进去。对使用者来说，省掉了“自己设计表、自己录数据”的环节，导入后就能查。
为什么强调 SQL 文件而不是 Excel？因为 Excel 适合看，不适合程序联动查询。SQL 文件可以直接在数据库里执行，配合parent_code做层级查询，几行语句就能拉出一棵区域树。这也是“数据库表 + SQL 文件”组合比单纯一份表格更实用的地方。
3.3 层级查询长什么样
有了parent_code，查某个省下面所有市就是一条普通查询：
-- 先找到目标省的编码，再用它查下级 SELECT code, name FROM region WHERE parent_code = (SELECT code FROM region WHERE name = '某省' AND level = 1) AND level = 2;这条语句先定位省的编码，再拿它当条件筛市。实际业务里通常不会用名称查，而是前端传来已选中的编码，直接WHERE parent_code = ?。理解这个模式，你就能自己扩展出“查某市所有区县”“查某区所有街道”的语句，逻辑完全一样，只是层级数字变一下。
4. 常见误区与易混概念：别把“区域表”当成“地址簿”
4.1 误区一：行政区域编码等于邮政编码
这两个最容易被混为一谈，因为都是数字、都和地址有关。易混的原因是它们经常出现在同一个收货表单里，看起来像一家人。区别在于：行政区域编码标识的是行政管理层级，一个区县一个码，和投递路线无关；邮政编码标识的是投递片区，可能跨行政边界，一个县里能有多个邮编。判断方法很简单——编码能不能顺着层级往上找到省？能，就是行政区域编码；不能，就别拿它做区域汇总。
4.2 误区二：五级表就是五个独立的表
有人一看“五级”，以为要建五张表分别存省、市、县、乡、村。易混的原因是“五级”听起来像“五份”。实际上主流做法是一张表加一个层级字段，所有级别混在一起，靠level和parent_code区分。这样查联动、做递归都方便，维护时也只改一处。区分方法：看表数量，如果只有一张带level的表，那就是单表多级设计；如果是五张表各管一级，关联起来会麻烦得多。
4.3 误区三：地名不变，数据就不用更新
很多人觉得行政区划很稳定，一份数据能用很多年。易混点在于“名字没变”不等于“关系没变”：有的地方撤县设区，名字改了；有的地方合并乡镇，上级换了；还有的只是编码调整。这些变化不会大张旗鼓通知你，但会让旧数据对不上新地址。判断一份数据是否够新，不能只看年份标签，要看它有没有覆盖近期的区划调整。这也是这类资源强调“更新版”的实际意义——不是噱头，是地址联动真的会翻车。
4.4 误区四：村级数据可有可无
做电商收货地址的人常觉得到区县就够了，村级是多余的。易混的原因是日常填快递确实很少填到村。但在网格化管理、户籍统计、本地服务覆盖这类场景里，村级恰恰是精度所在。区分方法看业务颗粒度：如果只需要“送到哪个区”，三级够用；如果要“落到哪个社区”，五级才有意义。别因为自己用不上就认为数据冗余，选数据前先想清楚业务要精确到哪一层。
5. 什么时候该用它、什么时候别硬上：一份边界判断
5.1 适合用的场景
这份五级行政区域数据库加 SQL 文件，最适合三类情况。第一类是地址表单联动：省市区街道社区逐级下拉，靠parent_code过滤，体验和主流电商一致。第二类是区域维度统计：按省、市、县汇总订单量、人口数、服务点数量，编码前缀让分组查询变得直接。第三类是数据清洗与对齐：把历史数据里五花八门的地址文字，通过编码映射到统一区域，减少“同地不同名”的混乱。
用之前先确认两件事：业务需要精确到第几级，以及数据覆盖的年份是否满足需求。如果只做省级报表，硬导五级数据只会让表变大、查询变慢；如果要做社区级服务，缺了村级就得回头补。
5.2 不适合硬上的场景
反过来，有几种情况别勉强。其一是只需要展示、不需要联动的静态页面，直接写死几个选项比建表更轻。其二是地址本身不规范的历史数据，编码映射前得先做清洗，否则脏数据灌进去还是脏。其三是对实时性要求极高的区划变更场景，任何离线数据都有滞后，得配合人工核对。判断标准就一条：这份数据解决的是“层级归属”问题，不是“地址文本纠错”问题，别指望它把错别字也修了。
| 场景 | 建议 | 原因 |
|---|---|---|
| 省市区三级下拉 | 用，取前三级即可 | 联动逻辑现成，数据够用 |
| 社区网格统计 | 用，必须含乡村两级 | 颗粒度决定统计精度 |
| 纯静态展示页 | 不必建表 | 写死选项更省事 |
| 地址文本纠错 | 不能单独靠它 | 需先做文本清洗再映射 |
5.3 一个具体例子：从导入到联动
假设某开发者要做一个小型登记系统，地址要选到街道。做法是先把 SQL 文件导入数据库，确认region表里level分布正常；然后前端第一级查level = 1的省，用户选中后拿code去查parent_code等于它的市，依此类推。整个过程不需要写复杂递归，就是三次同样的查询，只是层级参数不同。跑通之后再决定要不要放开到村级，避免一开始就把下拉框做得太长。
提示：导入后先跑一条
SELECT level, COUNT(*) FROM region GROUP BY level，看五级数量是否合理。某一级数量异常少，往往是数据缺失或层级字段标错，早点发现比上线后翻车强。
我自己的习惯是，每次拿到这类区域数据，先不急着接前端，而是把层级数量和几个典型地区的上下级关系手动查一遍，确认“儿子能找到爹、爹能找到儿子”再往下做。地址联动这种功能，出错往往不是代码写错，而是数据本身缺了一层。希望这份梳理帮到你，下次再看到“五级行政区域数据库”这几个字，你能一眼知道它是什么、该不该用。
本文还有配套的精品资源，点击获取
