全国五级行政区域数据库表SQL：导入、查询与维护实战

简介：面向从事政务系统开发、数据可视化、地址库建设及GIS相关工作的开发者与数据分析人员，提供一套可直接落库使用的全国五级行政区域数据。数据按省、地、县、乡、村五级组织，覆盖省自治区直辖市特别行政区、地级市地区自治州盟、县级市县区旗、乡级乡镇街道苏木以及村级行政村与社区，并附带行政区域名称与区域代码，可用于地址解析、区域联动下拉、统计报表分组等场景。压缩包共3个文件，以2个sql脚本和1个csv表格为主，sql可直接导入数据库建表与批量写入，csv便于Excel查看或二次清洗转换，整体约18.8MB。已有5021人学习下载，数据为2023年3月更新版本，层级完整、字段清晰，能省去自行采集与逐级拼接的工作量，适合需要快速搭建行政区划基础表或核对区域代码的读者参考使用。

1. 全国五级行政区域库：一份能直接灌进业务库的底表

做后台系统的都遇到过这种需求：用户注册要选省市区街道，订单要按行政区划统计，物流要匹配四级地址。每次都是从网上扒一份 Excel，字段名对不上、层级关系乱、更新日期不明，清洗一遍半天没了。这份 2023 年更新的全国五级行政区域数据库表加 SQL 文件，解决的就是这个反复造轮子的问题——省、市、区县、街道/乡镇、村/社区五级，带层级编码和父子关系，直接导入就能用。适合做电商地址库、政务数据归集、CRM 区域维度的后端和数据分析同学，尤其适合不想再维护一套自建区划表的小团队。下面按「表结构怎么设计 → SQL 怎么导 → 查询怎么写 → 坑在哪」拆开讲。

2. 五级区划表的结构设计与导入落地

拿到一份区划 SQL 文件，第一件事不是急着source，而是先看它的表结构和编码规则。五级行政区的核心难点不在数据量，而在层级关系的表达方式——用父子 ID 递归，还是用编码前缀匹配，直接决定了后面查询是写一行还是写十行。

2.1 编码规则与表字段的对应关系

国内行政区划有一套标准的统计用区划代码，省级 2 位、地级 4 位、县级 6 位、乡级 9 位、村级 12 位，逐级在父级编码后追加。这份库通常就是围绕这套编码组织的，常见字段包括code（区划代码）、name（名称）、parent_code（父级代码）、level（层级 1~5）、full_name（全称，如「某省某市某区」）。理解编码长度和层级的对应，是后面所有查询的地基。

这里有个选型判断：code一定要用字符串而不是整型。区划代码存在前导零（比如某些县级代码以 0 开头），用 INT 存会把零吃掉，导致和上级编码对不上，这是血泪经验。full_name属于空间换时间，写入时拼好，查询时直接取，避免每次递归。

2.2 建表与导入 SQL 的完整步骤

导入前先建库建表，字符集统一用utf8mb4，否则遇到生僻地名会乱码。下面这段是常见的建表语句，字段和上面表格对齐：

CREATE DATABASE IF NOT EXISTS region_db DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; USE region_db; CREATE TABLE region ( id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT, code VARCHAR(12) NOT NULL COMMENT '区划代码', name VARCHAR(64) NOT NULL COMMENT '名称', parent_code VARCHAR(12) NOT NULL DEFAULT '0' COMMENT '父级代码', level TINYINT NOT NULL COMMENT '层级1-5', full_name VARCHAR(255) DEFAULT NULL COMMENT '全称', PRIMARY KEY (id), UNIQUE KEY uk_code (code), KEY idx_parent (parent_code), KEY idx_level (level) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

建完表再导入数据文件。如果 SQL 文件里已经带了CREATE TABLE，就跳过建表直接导；如果只有INSERT，用上面的表结构。导入命令：

# 方式一：命令行直接灌，适合大文件 mysql -u root -p region_db < region_2023.sql # 方式二：进 mysql 客户端后 source，适合边看报错边导 mysql -u root -p # 进入后执行： # USE region_db; # SOURCE /path/to/region_2023.sql;

参数说明：-u后跟账号，-p回车后输密码，region_db是目标库名，<把文件内容喂给客户端。大文件（几十万行 INSERT）建议用方式一，客户端source在超大文件下容易卡顿。导入完成后先跑一句校验：

SELECT level, COUNT(*) AS cnt FROM region GROUP BY level ORDER BY level;

正常结果应该是层级越高数量越少，省约 30 多个、市 300 多、区县 2800 多、乡镇 4 万上下、村居 60 万量级。如果某一级数量明显偏少，多半是导入中途报错被截断，回去看终端有没有ERROR行。

2.3 用递归 CTE 查父子链路

有了parent_code，查「某村属于哪个省」这类需求就要递归。MySQL 8.0 以上支持递归 CTE，比在应用层循环查库干净得多：

WITH RECURSIVE chain AS ( -- 锚点：从目标节点开始 SELECT code, name, parent_code, level FROM region WHERE code = '目标村代码' UNION ALL -- 递归：逐级向上找父级 SELECT r.code, r.name, r.parent_code, r.level FROM region r JOIN chain c ON r.code = c.parent_code ) SELECT * FROM chain ORDER BY level;

逻辑说明：chain先取目标节点，然后每次用当前节点的parent_code去匹配上一级的code，直到顶级parent_code='0'匹配不到为止。ORDER BY level让结果从省到村排列。参数上唯一要改的是锚点里的code。如果数据库是 5.7 及以下，没有递归 CTE，常见做法是用编码前缀匹配替代：WHERE code LIKE CONCAT(LEFT('目标代码', 2), '%')取全省，逐级加长前缀取下级，虽然要多写几条，但不依赖版本。

2.4 按层级和前缀做批量查询

实际业务里更常见的是「给我某个市下面所有区县」这种批量取。用parent_code直接查最快：

-- 查某市下所有区县（level=3） SELECT code, name FROM region WHERE parent_code = '某市代码' AND level = 3 ORDER BY code;

如果只想按编码前缀圈范围（比如统计某省所有数据，不关心具体层级），用LIKE前缀匹配，配合code上的唯一索引能走范围扫描：

SELECT COUNT(*) FROM region WHERE code LIKE '某省前2位%';

注意LIKE 'xx%'是前缀匹配能走索引，LIKE '%xx'前后都带通配符就退化成全表扫描，几十万行的表上别这么写。这也是为什么code字段要建索引、要用定长字符串——前缀查询是这套表最高频的操作。

3. 区划数据的清洗、校验与增量维护

导入成功只是开始，真正让这份库在业务里站得住的是数据质量。区划数据有几个天然坑：重名、撤并、编码变更。这一章讲怎么在导入后做校验、怎么处理重名、以及 2023 版更新后老数据怎么对齐。

3.1 导入后的完整性校验脚本

导完先做三项校验：层级连续性、父子引用完整性、编码长度合规。用 SQL 一把梭：

-- 1. 检查是否存在孤儿节点（父级代码在表中找不到） SELECT c.code, c.name, c.parent_code FROM region c LEFT JOIN region p ON c.parent_code = p.code WHERE c.level > 1 AND p.code IS NULL; -- 2. 检查编码长度与层级是否匹配 SELECT level, LENGTH(code) AS code_len, COUNT(*) FROM region GROUP BY level, LENGTH(code) ORDER BY level; -- 3. 检查同级重名（同名不同代码，可能是撤并残留） SELECT parent_code, name, COUNT(*) AS cnt FROM region GROUP BY parent_code, name HAVING cnt > 1;

第一条查孤儿节点，结果非空说明有节点的父级被删了或编码写错，这种节点在递归查询时会断链。第二条验证编码长度，正常应该是 2/4/6/9/12 对应 1~5 级，如果出现 3 位、5 位的编码，说明数据源本身不规范，需要人工核对。第三条查同级重名，撤县设区、乡镇合并后经常出现同一父级下两个同名节点，业务上要按code区分而不是按name。

3.2 重名与撤并数据的处理策略

重名在区划数据里是常态，全国叫「城关镇」的能找出上百个，叫「朝阳区」的也不止一个。处理原则很简单：业务关联一律用code，展示才用name。如果前端下拉框只传了名称回来，后端必须结合parent_code或full_name做二次定位，否则一定串数据。

撤并的情况更麻烦。2023 版相对老版本，会有区县改区、乡镇合并、村居调整。如果业务库里存的是老代码，新库里查不到，就会出现「地址选不出来」。常见做法是维护一张映射表：

CREATE TABLE region_mapping ( old_code VARCHAR(12) NOT NULL, new_code VARCHAR(12) NOT NULL, remark VARCHAR(255) DEFAULT NULL, PRIMARY KEY (old_code) );

把撤并前后的代码对应关系录进去，查询时先查region，查不到再走region_mapping转一次。这张表不用全量，只录发生变更的节点即可，通常几百条。我一般会在导入新库后，拿老库的code集合和新库做一次LEFT JOIN差集，把差出来的老代码批量生成待确认清单，再人工补映射。

3.3 增量更新时避免全量重灌

区划数据一年更新一两次，没必要每次DROP TABLE重灌——业务表里可能已经存了region.id的外键。更稳的做法是按code做 upsert：

INSERT INTO region (code, name, parent_code, level, full_name) VALUES ('某代码', '某名称', '某父级', 3, '某省某市某区') ON DUPLICATE KEY UPDATE name = VALUES(name), parent_code = VALUES(parent_code), level = VALUES(level), full_name = VALUES(full_name);

ON DUPLICATE KEY UPDATE依赖uk_code唯一索引，命中就更新、没命中就插入。批量导入时把新数据先灌到临时表region_tmp，再用INSERT ... SELECT ... ON DUPLICATE KEY UPDATE一次性合并，比逐条快一个数量级。注意：如果新版本删除了某些节点（比如村居合并），upsert 不会删旧行，需要额外跑一次「新库没有但旧库有」的差集，确认后再决定是软删（加is_deleted字段）还是物理删。直接物理删有风险，业务表可能还引用着，建议先软删观察一个版本周期。

4. 避坑与常见问题排查

这一章是踩坑记录，每条都按「现象 → 原因 → 解决」写，都是导入和使用这份区划库时真实会撞上的。

现象：导入到一半报Incorrect string value，后面数据全没进去。原因：地名里有生僻字（比如某些带「土」「山」偏旁的罕见字），源文件是utf8而目标库是utf8mb3，三字节存不下四字节字符。解决：建库建表统一utf8mb4，导入前用SET NAMES utf8mb4;声明连接字符集，命令行导入时加--default-character-set=utf8mb4。

现象：递归查询查某村，结果只出来村和乡镇两级就断了。原因：中间某一级的parent_code和上级code对不上，常见于编码前导零被吞（用 INT 存过）或手工改过数据。解决：跑 3.1 的孤儿节点校验，定位断链的那一级，核对code和parent_code的字符串是否完全一致，包括长度。

现象：前端下拉框选了「朝阳区」，后端存下来的却是另一个城市的朝阳区。原因：只按name查询，重名节点全命中，取了第一条。解决：查询条件必须带parent_code或level，前端传值时同时传code而不是只传名称；后端接口参数设计上就要求code必填。

现象：LIKE '%某区%'模糊搜索区划，页面卡好几秒。原因：前后通配符导致全表扫描，60 万行的村居表上尤其明显。解决：搜索走full_name前缀匹配或加全文索引；如果只是按名称找，限定level缩小范围再匹配，别在五级全表上裸LIKE。

现象：新库导入后，老订单的地址编码查不到对应区划。原因：2023 版有撤并调整，老代码在新库里不存在。解决：建region_mapping映射表，查询时兜底转换；上线前用差集脚本把老代码清单跑出来，逐条确认映射关系，别等用户投诉再补。

5. 把区划库接进业务：缓存、接口与验证

数据落库只是第一步，真正让它在业务里跑顺，还得解决「查得快」和「查得对」两件事。区划数据的特点是读多写极少、总量可控（五级全量几十万行，内存里放得下），所以缓存策略和接口设计有明确的优化空间。

5.1 用两级缓存扛住高频地址选择

地址选择器是典型的高频低变更场景，每次用户点开都查库没必要。我一般做两级缓存：进程内缓存（如 Caffeine）存省市区三级的热数据，Redis 存全量五级按parent_code分组的列表。加载逻辑是启动时预热三级，四级五级按需加载后回填 Redis。

# 伪代码示意：按父级取子节点，先查本地缓存再查 Redis 再回源 def get_children(parent_code): # 1. 本地缓存命中直接返回 cached = local_cache.get(parent_code) if cached is not None: return cached # 2. Redis 命中则回填本地缓存 redis_key = f"region:children:{parent_code}" data = redis_client.get(redis_key) if data: result = json.loads(data) local_cache.put(parent_code, result) return result # 3. 回源数据库，写入两级缓存，过期时间设长（区划一年才变） rows = db.query( "SELECT code, name, level FROM region WHERE parent_code=%s ORDER BY code", (parent_code,) ) redis_client.setex(redis_key, 86400 * 30, json.dumps(rows)) local_cache.put(parent_code, rows) return rows

逻辑说明：parent_code作为缓存键，天然按层级分片；Redis 过期设 30 天，区划更新频率低，长过期没问题，更新时主动删对应 key 即可。参数上要注意本地缓存的容量上限，别把五级全量塞进程内存，只放三级足够覆盖 90% 的交互。

5.2 接口层的参数校验与返回结构

地址接口最容易出的问题是参数不校验，前端传个空parent_code就把全表捞出来了。接口层至少做三件事：parent_code非空校验、level范围校验（1~5）、返回字段裁剪（只回code、name、has_children）。has_children这个字段很实用，前端据此决定是否显示「展开下一级」的箭头，避免用户点了才发现是空列表。

-- 判断某节点是否有子节点，用于填充 has_children SELECT EXISTS( SELECT 1 FROM region WHERE parent_code = '某代码' LIMIT 1 ) AS has_children;

EXISTS命中即返回，比COUNT(*)快，配合idx_parent索引基本是毫秒级。批量场景下可以在取子节点时顺带用窗口函数或子查询标记，避免 N+1 查询。

5.3 上线前的验证清单

接进业务前，我会固定跑一遍验证：随机抽 10 个村，递归查上级链路是否完整到省；随机抽 10 个区县，查下级数量是否在合理区间；用老订单的 100 条地址编码做回查，确认映射兜底生效；压测地址选择接口，看 P99 是否在 50ms 内。这套清单跑通，区划这块基本就不会在上线后翻车。

从那以后我每次接区划数据，都强制先跑一遍孤儿节点校验和编码长度校验，再谈业务逻辑——数据本身不干净，后面写再多查询都是白搭。希望帮到你。

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