简介这套全国五级行政区域数据库表以SQL与CSV格式封装面向需要行政区划数据做业务系统开发、数据分析或地图可视化的开发者与实施人员。数据截至2023年3月更新涵盖省、地、县、乡、村五级行政区域的正式名称及区域代码并与常见行政区划层级保持一致。资源包共3个文件压缩后约18.8MB其中2份SQL文件分别提供分层明细表与便于联查的area_info_5结构CSV文件则为村级行政区行政村、社区数据便于导入各类工具。已有5013人在CSDN学习/下载适合直接导入MySQL等数据库用于报表统计、地址匹配或政务类项目初始化数据。相比手工整理这套表结构清晰、更新较新能节省大量数据处理与核对时间拿到后即可在项目中复用。1. 五级行政区域数据不是“多两张表”的事它决定了口径、权限和地址能不能闭环做业务系统的人早晚会撞上一面墙库里省市区县三级好好的一到乡镇和村居就抓瞎。上个月处理一份网格化台账发现乡镇和村两级全靠业务同学手工录入同一个村在系统里出现了六七种写法“某某镇某某村”和“某某乡某某村”统计出来根本对不上。这个标题讲的就是这类问题的公共底座一份按 2023 年口径整理的全国五级行政区域数据库表以及配套的 SQL 文件把省、市、区县、乡镇、村社区五层一次性落到你的数据库里。它解决的不是“能不能查出某个地名”而是统计口径、权限边界、地址联动这些真问题。适合数据工程师、后端开发以及做政务、电商、物流、网格化管理的从业者。2. 先把层级和代码规则捋清楚五级结构、数据来源与选型2.1 从省到村居五级分级与代码的组织方式全国行政区域在业务系统里最常见的切法是五级省级、地级、县级、乡级、村级。前两级不用多说难点往往在乡级和村级。实际交付的数据文件里每一行代表一个区域通常有四个核心字段区域代码、区域名称、层级、父级代码。只要把这四列搞对整张表的数据关系就立住了。区域代码是有规则的不是随便编的号码。省级代码占两位地级代码占四位县级代码占六位这是行政区划代码国家标准里定的底线乡镇和村没有全国统一编号常见做法是在县级六位代码后面继续扩位乡镇级扩到九位村级扩到十二位。也就是说你拿到一份数据先看代码位数就能判断它做到了哪一级。凡是说“五级全”的数据村级代码一定是十二位不然它下不到村。这里有个特别容易忽略的点乡镇级和村级代码的编码规则并不是全国统一发布的而是各省级区域自行管理。所以你会看到不同省份出来的九位码、十二位码风格不完全一样有的在六位码后直接加顺序号有的中间还插了街道办、管委会之类的特殊编码。处理这类数据时千万不能假设所有代码都是“633”的整齐结构先做一次代码长度分布统计再动手。2.2 数据源怎么选标准发布、整理版与自维护的区别做落地选型时数据源基本就是三选一各有各的坑。第一类是标准发布版本权威性最高但通常只覆盖到县级乡镇和村要靠自己再补更新节奏也慢第二类是社区整理的“全量版”省市区乡镇村五层都齐更新也及时但质量参差同一个区县在不同版本里可能名称后缀都不一样第三类是自维护也就是以自己业务库里积累的地址为准边用边补最贴合业务但初始成本高短期内很难凑齐全量。我一般的建议是以社区整理版为基础底座用标准发布的县级代码做校验再结合自维护补充业务特有的“虚拟区域”比如开发区、高新区这类与行政区重叠但不完全一致的机构。不要只依赖一份数据哪怕它号称 2023 年最新版也要留一手校验的余地。选型时还有一个维度容易被忽略这份数据是“静态快照”还是“可更新版本”。区划调整在一年内可能发生多次撤县设区、乡镇合并、村居拆分都是常态。标题里专门写“2023 年更新”恰恰说明版本意识很重要。拿到数据后第一件事不是导入而是看它有没有版本字段、有没有发布日期、有没有变更说明。2.3 表结构选型用一张冗余表还是两张范式表数据本身是一棵区域树但落库时有两种主流做法我用一张对比表说明方案表结构优点缺点适用场景宽表方案每行一个区域冗余省、市、区县、乡镇、村五列名称和代码查询快联表少前端好理解冗余大区划调整时要更新多行业务系统、报表、后端接口范式方案区域表 关系表区域表存自身信息关系表存父子关系数据干净调整父子关系只动一行查询要递归或多次 join逻辑复杂主数据管理、分析型平台做 OLTP 业务接口我建议用宽表做数据治理、主数据管理建议用范式表或至少保留一张关系表。很多团队图省事只建一张宽表结果遇到“某个镇从 A 区划到 B 区”这种调整时要 UPDATE 一大片行稍不留神就漏改。折中方案我比较推荐一张区域主表字段里带 code、name、level、parent_code、parent_path。parent_path 存完整祖先路径比如“省级代码,地级代码,县级代码”这样既保留了范式表的灵活性查询时又不用递归一碗水端平。3. 建表与入库一套能直接跑的 SQL 模板3.1 核心建表 SQL字段精度、默认值与索引设计拿到五级数据后第一件事是建表。很多人直接拿网上的 SQL 文件往里塞塞完才发现字段不够、索引不对、版本没法管理。这里给出一套我常用的模板你可以直接改表名和注释用。CREATE TABLE region ( code VARCHAR(12) NOT NULL COMMENT 行政区域代码省级2位/市级4位/县级6位/乡镇9位/村级12位, name VARCHAR(100) NOT NULL COMMENT 区域名称, level TINYINT NOT NULL COMMENT 层级1省 2市 3区县 4乡镇 5村居, parent_code VARCHAR(12) DEFAULT NULL COMMENT 父级代码省级的父级为空, parent_path VARCHAR(120) DEFAULT NULL COMMENT 父级路径链如 省级代码,市级代码,县级代码, is_leaf TINYINT NOT NULL DEFAULT 1 COMMENT 是否叶子节点1是 0否, region_version VARCHAR(20) NOT NULL COMMENT 数据版本如 2023, created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT 创建时间, updated_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT 更新时间, PRIMARY KEY (code, region_version), KEY idx_parent_code (parent_code), KEY idx_level (level) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT五级行政区域表;这段 SQL 里有几个设计是踩过坑才加上的。主键用(code, region_version)联合主键而不是单列 code原因是同一份 2023 年数据里code 本身唯一但当你后续引入 2024 年版本时同一个 code 会在不同版本出现用联合主键就能避免“新版本覆盖旧版本”的翻车场景。parent_path这个字段很多人觉得冗余但它能让你免写递归查询后文会专门用它做区域树查询。is_leaf是用来标识叶子节点的村居级就是叶子乡镇级以上不一定这个字段在生成级联下拉菜单时非常有用。字符集选 utf8mb4别用 utf8因为村级名称里会有特殊字符和生僻字utf8 在某些 MySQL 版本上存不进去。3.2 从原始 SQL 到标准 CSV清理、补全与代码修正市面上的 SQL 文件质量参差有的带注释头有的用分号分隔有的列顺序跟你建的表不一致。我从来不会直接把下载的 SQL 文件一股脑 source 进去而是先转成标准 CSV再做一次清洗。这个过程用 Python 处理最顺手。import csv import re def parse_raw_line(line: str): 解析原始数据行兼容逗号和分号分隔忽略注释行 line line.strip() if not line or line.startswith(#) or line.startswith(--): return None parts re.split(r[,;], line.strip()) parts [p.strip().strip(\) for p in parts] if len(parts) 4: return None code, name, level parts[0], parts[1], int(parts[2]) parent_code parts[3] if parts[3] else return code, name, level, parent_code def build_parent_path(region_map, code): 根据父级代码回溯生成完整路径 path [] cur code seen set() while cur and cur in region_map and cur not in seen: path.append(cur) seen.add(cur) cur region_map[cur] return ,.join(reversed(path)) rows [] region_map {} with open(raw_region.sql, r, encodingutf-8) as f: for line in f: parsed parse_raw_line(line) if parsed: code, name, level, parent_code parsed region_map[code] parent_code rows.append((code, name, level, parent_code)) with open(region_2023.csv, w, encodingutf-8, newline) as f: writer csv.writer(f) writer.writerow([code, name, level, parent_code, parent_path]) for code, name, level, parent_code in rows: parent_path build_parent_path(region_map, parent_code) writer.writerow([code, name, level, parent_code, parent_path])这段脚本的核心是build_parent_path函数。它从当前区域的父级开始回溯一路往上走直到省级然后把路径倒序拼接得到类似“省级代码,市级代码,县级代码”的完整链路。这里的关键参数是seen集合防止原始数据里出现循环引用导致死循环——这种场景在手工整理的数据里真的存在我在实际数据里抓到过两次环。处理完 CSV 后别急着入库先做一轮质量检查统计各级别行数、检查 code 是否重复、检查 parent_code 是否都能在表里找到。这三个检查能拦掉 80% 的脏数据问题。3.3 批量导入用 LOAD DATA 与事务把数据安全落库CSV 出来后导入就很简单了。数据量几万行用 INSERT 一条条插也能跑但没必要用 MySQL 的 LOAD DATA 命令几秒就能完成。LOAD DATA LOCAL INFILE /tmp/region_2023.csv INTO TABLE region CHARACTER SET utf8mb4 FIELDS TERMINATED BY , OPTIONALLY ENCLOSED BY LINES TERMINATED BY \n IGNORE 1 LINES (code, name, level, parent_code, parent_path, dummy, dummy) SET is_leaf IF(level 5, 1, 0), region_version 2023;注意这里IGNORE 1 LINES跳过了 CSV 的表头dummy占位符用来跳过 CSV 里没有的字段SET子句在导入时动态计算is_leaf和region_version省去了导入后再 UPDATE 一整张表的时间。OPTIONALLY ENCLOSED BY 是为了兼容名称里带逗号的情况比如“某某社区居委会”这个参数不加名称会被错误地截断。导入完成后立刻做两个动作一是统计各级别行数跟源文件的行数对账二是随机抽查十几个村级代码手动到地图或官方区划查询里比对。对不上就说明清洗逻辑有 bug不要带着疑问往下走。4. 用 SQL 和 Python 管理维护查父级、同步更新与版本记录4.1 用递归或路径字段查询完整区域树表里已经存了parent_path查询任意节点的完整路径就不再需要递归。举一个最常见的场景根据一个村级 code查出它所属的省市区。SELECT code, name, level, parent_path FROM region WHERE region_version 2023 AND (code 目标村级代码 OR FIND_IN_SET(code, ( SELECT parent_path FROM region WHERE code 目标村级代码 AND region_version 2023 )) 0) ORDER BY level;这段 SQL 的核心是FIND_IN_SET。子查询先取出目标村的parent_path比如“省级代码,市级代码,县级代码,乡镇代码”外层查询再判断code是否落在这个路径集合里。这样一次查询就能把从省到村的整条链取出来在代码里拼树形结构非常方便。如果你的 MySQL 版本支持递归 CTE也可以用WITH RECURSIVE从关系表里逐层向上遍历但说实话生产环境里parent_path这种预计算字段的查询效率明显更高可读性也更好。我这边所有线上接口都用FIND_IN_SET方案递归 CTE 只在做数据校验时用。4.2 版本化存储每次更新都留下快照区划数据是会变的所以版本管理不是可选项是必选项。常见的做法是学习数据仓库的 SCD 思路把版本字段直接放进主表每次更新不覆盖旧数据而是插入新版本。-- 复制旧版本到历史表业务表留最新 CREATE TABLE region_history AS SELECT * FROM region WHERE region_version 2023; -- 新版本导入前先把业务表里的旧版本标记归档 UPDATE region SET region_version CONCAT(region_version, _archived) WHERE region_version 2024;这两条 SQL 做的事很简单历史表保留完整旧快照业务表里只留最新版本。日常查询都带region_version 2024条件归档数据如果需要回溯去历史表里查就行。注意第二段CONCAT加后缀的方式只适用于“同一年内多次小更新”如果你一年只更新一次直接插入新版本号更干净。版本化带来的好处是你可以做数据变更对比。比如统计 2023 版和 2024 版之间哪些 code 消失了、哪些 code 是新增的、哪些名称改了。这个对比结果就是区划调整的变更日志业务部门非常需要。4.3 更新同步策略全量替换还是增量打补丁每次拿到新版本数据是整表清空重灌还是只更新有变化的部分我的建议分场景。如果是自己维护的内部库数据量撑死几万行全量替换最简单、最不容易出错步骤如下-- 1. 把新版本 CSV 先导入到一张临时表 CREATE TABLE region_staging LIKE region; LOAD DATA LOCAL INFILE /tmp/region_2024.csv INTO TABLE region_staging CHARACTER SET utf8mb4 FIELDS TERMINATED BY , OPTIONALLY ENCLOSED BY LINES TERMINATED BY \n IGNORE 1 LINES (code, name, level, parent_code, parent_path, dummy, dummy) SET is_leaf IF(level 5, 1, 0), region_version 2024; -- 2. 对比新旧版本记录变更到 changelog 表 INSERT INTO region_changelog (code, old_name, new_name, change_type) SELECT COALESCE(o.code, n.code) AS code, o.name AS old_name, n.name AS new_name, CASE WHEN o.code IS NULL THEN ADD WHEN n.code IS NULL THEN DELETE WHEN o.name n.name THEN RENAME ELSE UNCHANGED END AS change_type FROM region o LEFT JOIN region_staging n ON o.code n.code WHERE o.region_version 2023 AND (o.code IS NULL OR n.code IS NULL OR o.name n.name); -- 3. 确认无误后切换版本 RENAME TABLE region TO region_backup, region_staging TO region;这套流程的关键在于“临时表 对比 原子切换”。先把新数据导到region_staging对比生成region_changelog确认变更合理后用RENAME TABLE一步切换旧表自动变成备份。这样全程不锁业务表出问题还能通过改名把旧表切回来相当于给更新上了后悔药。对比脚本里的CASE WHEN是变更分类的核心新增、删除、改名一目了然。区划调整里最常见的三类变更全都被覆盖到了。如果是做对外提供数据的服务方不建议只发一个全量文件最好附带 changelog让下游系统自己决定怎么合并。5. 五级区域数据落地的 5 个高频坑现象、原因与解法5.1 source 导入报错“列数不匹配”现象拿到 SQL 文件后在 MySQL 里执行source报错Column count doesnt match value count有时候直接中断导入半途而废。原因很多整理版 SQL 文件不是标准 INSERT 语句文件头部有注释、SET 语句或者数据行里名称字段带逗号导致 MySQL 解析时把字段切错位置。另一个常见原因是原始文件里混入了分号分隔的行和逗号混用。解决不要用source直接灌原始文件。先head -n 50看文件头识别它是逗号分隔还是分号分隔再按第 3.2 节的 Python 脚本统一转为 CSV用LOAD DATA导入。如果文件实在太大用split按行切分分批导入避免一次解析几万行。5.2 村级名称后缀不统一统计口径直接翻车现象同一个村在表里叫“某某村委会”在业务系统里叫“某某村”按名称 group by 统计时一个村被拆成两行数据对不上。原因采集源不同。整理版数据可能混合了民政口径的“村委会”和统计口径的“村”还有一些社区叫“居委会”“社区居委会”后缀五花八门。解决在区域表上增加一个normalized_name字段导入时把“村委会”“居委会”这类后缀统一剔除或统一映射。最简单的方式是 SQL 里做一次清洗UPDATE region SET normalized_name CASE WHEN name LIKE %村委会 THEN REPLACE(name, 村委会, ) WHEN name LIKE %居委会 THEN REPLACE(name, 居委会, ) ElSE name END WHERE region_version 2023;注意这个更新只改normalized_name原始的name必须保留因为对外展示和公文口径要用原始名称。统计用规范名展示用原始名两列各司其职才不会再翻车。5.3 行政区划代码被复用旧数据串到新区域现象一张业务表存了几年前的地区代码2023 年统计时发现同一个 code 对应的地名已经变了历史数据全算到了新区域头上。原因区划代码存在回收和复用机制。撤县设区后原县级代码被释放新设立的区可能拿旧代码复用。如果业务表外键只关联 code不关联版本历史数据必然串区域。解决业务表在关联区域表时必须同时带上数据日期用日期去匹配对应版本的区域数据。如果业务表设计时没有时间维度至少要在区域表里维护valid_from和valid_to字段查询时用日期区间过滤或者采用第 4.2 节的版本快照表让历史数据永远关联历史版本。5.4 同一个村出现两个父级关系表出现环现象在构建区域树时递归查询死循环或者一个村级节点同时挂在两个乡镇下面级联菜单出现重复。原因开发区、高新区、托管区这类特殊区域与行政区划重叠同一个村在行政区划上属于 A 镇在管理上归 B 街道办托管整理数据时两边都保留了一条记录。解决区域表的主键是(code, region_version)同一个 code 不能重复但确实存在“一个地域两个编码”的情况那就只能让一个作为主编码另一个作为别名。我一般会在区域表加一个alias_code字段保存托管区的关联代码查询时默认只走主编码特殊业务需要再走别名。千万不要在同一张表里让一个 code 拥有两个 parent_code做不出来不说后患无穷。5.5 大 SQL 文件直接导入 DB 卡死现象一个几十 MB 的 SQL 文件执行到一半数据库无响应CPU 飙高最后只能 kill 进程表还可能被锁住。原因原始 SQL 文件里可能是一条超长的多 VALUES INSERT超过了 MySQL 的max_allowed_packet或者整个文件没有分批提交事务日志撑到极限。解决第一调大max_allowed_packet到 64M 或 128M第二不要用source用LOAD DATA第三如果必须用 INSERT用 Python 把多 VALUES 拆成每 1000 条一组。另外养成习惯导入前先BEGIN导入完COMMIT别让 MySQL 自己在一个事务里处理全部数据。6. 数据入库之后用校验脚本和区域联动把人从维护里解放出来数据入库只是起点真正要解决的日常问题是“怎么保证它一直是对的”。我给自己定了一套校验脚本每次数据更新后跑一遍十分钟内确认结果。首先是对账统计各级别行数省、市、区县、乡镇、村五层数量分别和源文件对比偏差超过 1% 就要查。其次是完整性检查查 orphan 节点也就是parent_code在表里不存在的记录一条都不能有再查是否有重复 code联合主键会挡住但要留意 CSV 清洗阶段是否把 code 改错。最后是抽样人工比对随机抽 20 个村级代码用地图服务或官方区划查询工具核对名称这一步最费时间但最有效。校验通过后区域数据就可以接入业务了。最常见的用法是五级级联下拉和省市区乡镇村地址联动。后端只暴露一个接口接收parent_code和level两个参数查询语句简单到不需要缓存SELECT code, name FROM region WHERE region_version 2023 AND parent_code ? ORDER BY code;前端拿到哪个层级就请求哪个层级的子节点由于表里有is_leaf字段前端可以判断到第五级就不再出现“下一级”按钮。这套逻辑不会因为区划调整而改动代码只要后端更新数据版本前端行为自动跟着变。我吃过最大的亏是觉得数据只进不出、不用维护结果半年后业务同学反馈“新入驻的街道查不到”才发现区划调整没有及时同步。从那以后养成了习惯每次更新数据都在代码仓库里留一份变更说明标注版本号、发布日期、变更类型和影响范围业务系统发布时顺带把区域版本号一起升级。这样无论过去多久都能说清楚当时用的是什么底账。五级区域数据不是一份一次性交付的静态文件而是一个需要持续维护的公共基础设施。希望这篇梳理能帮你在落地的路上少踩几个坑少走我走过的弯路一次把表结构、导入流程和更新机制都搭对。本文还有配套的精品资源点击获取