简介面向从事地理信息、人口统计、物流规划与数据库开发的人员这份GB/T 2260全国行政区划代码数据集提供了一套标准化的四级区划编码参考覆盖省/直辖市、市、县及乡镇街道等层级可用于搭建行政区划表、做数据匹配与地域维度分析。压缩包共4个文件包含SQL脚本、Access数据库、TXT文本和XLSX表格整体约5.01MBSQL脚本便于导入MySQL建表Access文件可脱离SQL环境直接查看TXT与XLSX则方便在Excel中筛选、核对和二次整理。数据量约46462条版本为2017年最新版能支撑人口统计、GIS、物流规划与市场分析等场景也适合作为开发测试的基础字典表。使用时需留意行政区划调整带来的时效性。目前已有1105人学习。1. 项目定位一份 GB/T 2260 行政区划代码 SQL 能省掉多少脏活做后台系统的都躲不开选省市区这个需求用户注册要选、订单要按地区统计、门店要挂行政区划编码。第一反应是找接口接口要授权、有限流、赶上对方机房抖动还得背锅第二反应是自己维护一张表于是就有了无数个从网页上扒下来再手工补的下午补完之后发现某个县级市根本不存在。这份资源解决的就是最底层那一层把 GB/T 2260 行政区划代码整理成可直接导入关系型数据库的 SQL 脚本省、地、县三级齐全字段带名称、层级、父级编码导进去就能查不用再对着标准文本一行行敲。适合做 SaaS 多租户地域配置的、做物流地址库的、做数据看板按地区聚合的以及任何不想为了选个省再引一个第三方 SDK 的团队。数据是静态的但静态恰恰是它的价值——你把它当成字典表放进自己的库主动权就在自己手上。2. 数据骨架六位编码规则与省市区建表语句怎么对应2.1 GB/T 2260 的六位编码到底怎么切行政区划代码是 6 位定长数字字符串不是整数这个细节决定了后面所有字段类型的选择。结构上分三段每段两位位段含义取值说明第 1-2 位省级01-99 之间分配用于标识省、自治区、直辖市第 3-4 位地级00表示该省直接管辖县级单位01-99 为地级市、自治州、地区第 5-6 位县级00表示该地级单位直接管辖01-99 为市辖区、县、县级市一个省级单位的代码形如900000它下辖的地级单位就是900100、900200、900300这样按顺序往后排一个地级单位的代码形如900100它下辖的区县则是900101、900102。所以严格意义上说省级代码就是后四位全是00的代码地级代码就是后两位是00的代码这个规律可以直接用来校验数据是否自洽。很多数据包里没有单独的 level 字段靠的就是这条规则现算。值得单独拎出来说的是直辖市和特殊县级单位。直辖市的省级代码下面通常不会直接挂区县而是先挂一层市辖区当作伪地级中间两位用01、02之类而省直辖的县级行政单位中间两位常见90这样的特殊段父级直接指回省级代码。这两种形态是后面查询断链的主要来源建表的时候必须留有兜底余地。解析一个代码属于哪一层写个小函数就够了def parse_code(code: str) - dict: 把 6 位行政区划代码拆成省/市/县三级 if not code or len(code) ! 6 or not code.isdigit(): raise ValueError(f非法区划代码: {code}) if code[2:] 0000: level 1 # 后四位全 0省级 elif code[4:] 00: level 2 # 后两位全 0地级 else: level 3 # 其余都是县级 return { province: code[:2] 0000, # 省级代码 city: code[:4] 00, # 地级代码 county: code, # 县级代码 level: level, }parse_code的入参必须是字符串而不是整数因为01这种省级代码一旦被当成整数解析前导零直接消失整个层级关系就废了。返回值里的province和city是向上补齐的结果拿来反查父级最方便level则用于判断这条记录该落在哪一级。另一个高频混淆点是 6 位行政区划代码和 12 位统计用区划代码的区别。后者是统计口径前 6 位与行政区划代码对齐后 6 位是居委会、村委会的标识长度和含义都不同。有人把 12 位数据直接塞进 6 位字段结果被截断得一塌糊涂。做业务地址库时用 6 位就够只有做人口普查级别的统计才需要 12 位。2.2 一张自关联表还是拆成三张表拿到 SQL 包之后第一个决策是表结构。常见三种形态各有取舍方案优点缺点适用场景单表自关联code parent_code level结构简单增删改只动一处天然支持任意层级扩展三级联动要自连接两次或用递归 CTE绝大多数业务系统拆成 province / city / county 三张表查询直观前端字段对接直白数据冗余层级调整要同时改三张表层级绝对固定、只读的展示场景单表 物化路径path 存900000/900100/900101查某节点的整棵子树一条 LIKE 搞定路径维护成本高任何父级变更都要级联更新需要频繁查下级的组织架构类系统我一般会选第一种单表自关联。理由很实在行政区划虽然看着是三级但业务上经常出现省直辖县级单位这种跨级挂载三表模型的county.city_code就得填空值查询时到处写IS NULL判断血泪经验。单表只多一个 level 字段什么形态都能容纳。对应的建表语句CREATE TABLE sys_region ( id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT COMMENT 自增主键, code CHAR(6) NOT NULL COMMENT GB/T 2260 六位行政区划代码, name VARCHAR(64) NOT NULL COMMENT 行政区划全称, short_name VARCHAR(32) DEFAULT NULL COMMENT 简称去掉省/市/县等后缀, parent_code CHAR(6) DEFAULT NULL COMMENT 父级代码省级为 000000, level TINYINT NOT NULL COMMENT 层级 1省 2市 3县, pinyin VARCHAR(64) DEFAULT NULL COMMENT 拼音全拼用于模糊检索, initial CHAR(1) DEFAULT NULL COMMENT 拼音首字母用于城市选择器索引, status TINYINT NOT NULL DEFAULT 1 COMMENT 1有效 0已撤销或合并, PRIMARY KEY (id), UNIQUE KEY uk_code (code), KEY idx_parent (parent_code), KEY idx_level_name (level, name) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COLLATEutf8mb4_general_ci COMMENT行政区划代码表;code用CHAR(6)而不是INT这是整张表最不能妥协的地方前导零丢一次就得全表重导。name给到 64 是因为确实存在长度夸张的自治州全称32 位会截断。short_name是给前端展示用的列表页放全称太挤。status字段很多数据包里没有建议自己加上区划合并撤销是常态历史订单引用的旧代码不能直接删标个失效最省心。pinyin和initial也是数据包之外的补充前端城市选择器要靠首字母索引导入后跑个脚本批量生成一次就行。uk_code唯一索引是数据质量的最后一道闸重复代码在导入阶段就该被拦下来别等到业务层查出两条同名记录再去排查。idx_parent服务于三级联动idx_level_name服务于后台按名称搜索两个索引基本覆盖日常查询。2.3 包里通常有哪些文件、各自干什么用这类资源一般会按数据库方言拆成几份常见构成是一份 MySQL 版的全量脚本包含建表语句加批量 INSERT一份 PostgreSQL 版可能用COPY语句做高速导入部分还会附一份 SQLite 文件拿到手直接能开。文件命名通常带年份或版本号方便区分数据截止时间。用之前先确认三件事建表语句里的字段类型是不是CHAR(6)、INSERT 是不是批量合并成多值形式、脚本开头有没有DROP TABLE IF EXISTS。批量 INSERT 对导入速度影响极大一条一条插几千行要跑几分钟合并成INSERT INTO ... VALUES (...),(...),(...)之后通常几秒就完。DROP TABLE存在于全量包里是正常的但如果你的库里有自己加的字段直接执行会把它们一起清掉所以正式环境导入前先看一下脚本头部把它改成CREATE TABLE IF NOT EXISTS或者先备份。3. 落库实战SQL 脚本导入、三级联动查询与索引调优3.1 三种导入姿势各自适合什么场合MySQL 场景下最直接的是命令行重定向# 指定字符集避免中文变成问号 mysql -u root -p \ --default-character-setutf8mb4 \ mydb region_gbt2260.sql--default-character-setutf8mb4这个参数不能省。客户端默认字符集如果是latin1脚本里的中文会被按错误编码解释导入完成后name字段整列都是问号或者乱码方块而且这种损坏是不可逆的只能删表重来。mydb要提前建好并确认 collation 是utf8mb4_general_ci或utf8mb4_0900_ai_ci库的字符集和客户端字符集不一致一样会出问题。如果脚本太大或者需要边导边看报错进 MySQL 交互界面用source更灵活-- 先切库再执行脚本报错会逐条打印出来 USE mydb; SET NAMES utf8mb4; SOURCE /path/to/region_gbt2260.sql;SET NAMES utf8mb4的作用和命令行参数一致只是改成在会话里设置。SOURCE后面必须是服务器能访问到的绝对路径写成相对路径经常报Failed to open file很多人卡在这一步以为是文件权限问题。PostgreSQL 和 SQLite 的处理方式略有差异。PostgreSQL 用psql -f region.sql -U user -d mydb如果脚本里是COPY ... FROM stdin的形式必须用psql执行不能走图形客户端否则会报COPY 数据必须来自标准输入。SQLite 最简单sqlite3 region.db region.sql或者进交互界面.read region.sql都行注意 SQLite 的类型系统是动态的CHAR(6)只是声明写入时不会强制截断所以导入后仍然要用 SQL 校验一遍长度。导入完先跑一条计数确认SELECT level, COUNT(*) AS cnt FROM sys_region GROUP BY level ORDER BY level;省级通常在 30 到 40 之间地级在 300 到 400 之间县级在 2800 到 3000 之间。这三个数字记在脑子里是判断数据完不完整的第一个信号。数量对不上后面所有查询都白搭。3.2 三级联动的几种写法与性能差异最朴素的做法是前端一次性拉全量后端一条 SQL 返回所有有效记录前端自己按parent_code组装成树SELECT code, name, parent_code, level FROM sys_region WHERE status 1 ORDER BY level, code;三千行左右的数据JSON 序列化后大概几百 KBgzip 之后一百多 KB首次加载拉一次存前端内存后续切换省市完全不发请求。这是最省事也最快的方案适合管理后台这种对首屏体积不敏感的场景。参数上status 1过滤掉已撤销的区划ORDER BY level, code保证返回顺序稳定前端组树时不用再排序。移动端或者接口不能返大对象时改成按需查询-- 查某个省下面所有地级单位 SELECT code, name FROM sys_region WHERE parent_code 900000 AND status 1 ORDER BY code; -- 查某个地级单位下面所有区县 SELECT code, name FROM sys_region WHERE parent_code 900100 AND status 1 ORDER BY code;这里有个坑省直辖县级单位的parent_code直接指向省级所以用第一条 SQL 查某省的下级返回结果里会混着地级市和省直辖县。前端如果无脑当成市渲染用户就会看到一个县级单位出现在市级下拉框里。解决办法是在查询里带level字段前端按 level 分流或者干脆把省直辖县挂到一个虚拟的市级节点下面。需要查整棵子树时用递归 CTEMySQL 8.0 以上和 PostgreSQL 都支持WITH RECURSIVE region_tree AS ( -- 锚点从根节点开始 SELECT code, name, parent_code, level, 1 AS depth FROM sys_region WHERE code 900000 UNION ALL -- 递归部分逐层向下找子节点 SELECT r.code, r.name, r.parent_code, r.level, t.depth 1 FROM sys_region r JOIN region_tree t ON r.parent_code t.code WHERE r.status 1 AND t.depth 5 -- 限制递归深度防止脏数据死循环 ) SELECT * FROM region_tree ORDER BY code;depth 5这个限制不是多余的。如果数据里存在 A 的父级是 B、B 的父级又是 A 这种脏数据没有深度限制的递归会一直跑下去把连接池耗干。有status过滤也一样脏数据不一定 status 不对。加上限之后最多扫五层配合code排序输出结果直接就是树的前序序列。按名称模糊搜索是另一个高频需求后台经常要让运营输入某某县直接跳转SELECT code, name, level, parent_code FROM sys_region WHERE name LIKE CONCAT(%, 关键字, %) AND status 1 LIMIT 20;LIKE前置通配符会让idx_level_name索引失效变成全表扫描。三千行的表扫一遍也就一两毫秒完全能接受但如果这张表被其他业务表 join 了几十万次就该考虑把搜索单独拆出去或者用拼音首字母做前缀匹配——输入hz命中杭州这类initial字段上的索引是能吃到的。3.3 缓存策略与查询计划确认行政区划数据是典型的读多写零缓存收益极高。我通常的做法是在应用启动时把全量数据加载进本地缓存三千条记录占内存不到 1MB之后所有查询都走内存数据库只作为持久化存储-- 只捞必要字段减小缓存对象体积 SELECT code, name, short_name, parent_code, level, initial FROM sys_region WHERE status 1;如果服务是多实例部署本地缓存各自加载一份也没问题数据量小、更新频率低不需要 Redis 那一层。真有增量更新需求时发个广播消息让各实例重载就行比引入分布式缓存简单得多。索引是否被正确使用用执行计划确认一遍最稳妥EXPLAIN SELECT code, name FROM sys_region WHERE parent_code 900000;type应该是refkey应该是idx_parentrows是几十这个量级。如果type显示ALL说明索引没走常见原因是parent_code的字符集和查询条件的字符集不一致隐式转换导致索引失效。还有一种情况是查询条件写成了parent_code 900000数字MySQL 会把字符串列转成数字比较索引同样失效这个坑很隐蔽因为 SQL 不报错只是慢。4. 数据校验怎么证明这份代码表没有缺漏、错位和过期4.1 三条 SQL 把结构问题全捞出来导入完成不等于数据可用尤其是从各种渠道流转过来的 SQL 包缺行、错位、父级指向不存在的记录都可能存在。下面三条 SQL 建议每次导入后都跑一遍-- 1. 父级不存在的孤儿节点 SELECT r.code, r.name, r.parent_code, r.level FROM sys_region r LEFT JOIN sys_region p ON r.parent_code p.code WHERE r.level 1 AND p.code IS NULL; -- 2. 代码重复 SELECT code, COUNT(*) AS cnt FROM sys_region GROUP BY code HAVING COUNT(*) 1; -- 3. 名称重复但代码不同同名不同层级需要人工确认 SELECT name, COUNT(*) AS cnt, GROUP_CONCAT(code) AS codes FROM sys_region WHERE status 1 GROUP BY name HAVING COUNT(*) 1;第一条查孤儿节点结果非空说明有记录的父级代码在表里找不到对应行这种记录在三级联动里永远显示不出来属于藏起来的脏数据。第二条靠唯一索引就能拦住但如果索引是后加的历史数据可能已经重复了。第三条不是错误跨省同名县确实存在但同一个省内出现同名同级单位就该人工看一眼了大概率是数据源拼错了。4.2 用编码规则反推层级是否自洽六位编码自带校验能力代码本身就能告诉你它该属于哪一层。用一条 SQL 把所有代码形态和 level 字段对不上的记录挑出来SELECT code, name, level, CASE WHEN SUBSTRING(code, 3, 4) 0000 THEN 1 WHEN SUBSTRING(code, 5, 2) 00 THEN 2 ELSE 3 END AS expected_level FROM sys_region WHERE level CASE WHEN SUBSTRING(code, 3, 4) 0000 THEN 1 WHEN SUBSTRING(code, 5, 2) 00 THEN 2 ELSE 3 END;expected_level完全由代码推导出来和存储的level不一致就说明这条记录有问题。常见情况是数据源把省级单位标成了 level 2或者把县级市标成了 level 2——县级市的代码后两位不是00规则上就应该是 3。这种字段错位在按 level 分组统计时会让数字看着很奇怪但对查询本身没影响所以特别容易被忽略等到做权限按层级过滤时才暴露。再补一条父级层级校验确认地级的父级必须是省级SELECT c.code, c.name, c.level, p.code AS parent_code, p.level AS parent_level FROM sys_region c JOIN sys_region p ON c.parent_code p.code WHERE c.level - p.level 1;正常情况下子级 level 永远比父级大 1。差值不等于 1 说明中间跳级了典型的是县级单位直接挂在省级下面省直辖县父级 level 是 1、子级 level 是 3差值是 2。这类记录不一定是错的但必须心里有数查询逻辑要能兜住。4.3 新旧版本比对增量到底变了什么区划调整每年都有拿到新版数据包之后别急着整表覆盖先做一次 diff 看看影响面import csv def load(path): with open(path, newline, encodingutf-8) as f: return {row[code]: row for row in csv.DictReader(f)} old load(region_old.csv) new load(region_new.csv) added new.keys() - old.keys() # 新增代码 removed old.keys() - new.keys() # 撤销代码 renamed [c for c in new.keys() old.keys() if new[c][name] ! old[c][name]] # 更名 print(f新增 {len(added)} 条撤销 {len(removed)} 条更名 {len(renamed)} 条) for c in sorted(added)[:20]: print(, c, new[c][name]) for c in sorted(removed)[:20]: print(-, c, old[c][name]) for c in sorted(renamed)[:20]: print(~, c, f{old[c][name]} - {new[c][name]})load函数把 CSV 读成以 code 为键的字典两个字典做集合运算就能拿到三类变更。只打印前 20 条是为了看趋势真实场景里应该把完整清单落成一张region_change_log表记录变更时间、变更类型、变更前后名称。有了这张表历史订单里的旧代码在展示时可以查一张映射表还原成新名称不用去猜。撤销的代码不要物理删除把status置 0 就够了删掉之后再想追溯就真的没有后悔药了。5. 避坑排查行政区划数据落地最容易翻车的五件事5.1 编码与字符集层面的坑现象导入完成后name字段整列是问号或者中文变成一堆看不懂的方块。原因基本是两个一是mysql客户端默认字符集不是utf8mb4脚本里的 UTF-8 字节被按 latin1 解释后存进库二是库或表的 collation 设成了latin1_swedish_ci即使客户端对了落盘时也会被转一次。这两种损坏都不可逆改字符集不会把已有数据修好。解决方式是在导入命令里显式带上--default-character-setutf8mb4并且提前确认SHOW CREATE DATABASE mydb输出的字符集是utf8mb4。已经导入坏了的表只能TRUNCATE之后重来所以在导入前养成先建库、先查字符集的习惯比事后修数据便宜得多。现象导出的 CSV 用 Excel 打开省级代码01变成1再存回去就丢了前导零。这是 Excel 把纯数字列当成数值类型处理的经典行为跟 SQL 无关。字段本身是CHAR(6)库里存的是对的问题出在导出-编辑-再导入这条链路上。解决方式是导出时给代码列强制加文本格式或者在 CSV 里用制表符前缀如果一定要用 Excel 做人工核对把该列格式先设成文本再粘贴数据别直接双击打开。5.2 层级结构层面的坑现象某直辖市的区县在三级联动里选不出来市级下拉框是空的。直辖市下面有一层市辖区作为伪地级区县的真实parent_code指向的是这个伪地级而不是省级代码。如果前端逻辑是选中省之后按省级代码查子节点查到的只有伪地级这一条再往下就断了。解决方式有两种一是查询时把 level 的判断放宽省级节点的子节点同时兼容parent_code 省代码和parent_code IN (该省下所有市级代码)二是在数据层做一次归一化插入时把直辖市的区县parent_code直接改写成省级代码同时把city字段另存到一个city_code列里保留原始信息。我一般选第二种SQL 里多写一次 UPDATE前端逻辑就能保持统一不用到处写特殊判断。现象省直辖县级单位成了孤儿任何一级下拉框都找不到它。这类单位的parent_code指向省级代码但它自己的 level 是 3中间那一层不存在。前端的省-市-县三段式联动天然容不下这种跨级挂载。解决办法是在构建树的时候做一次兜底如果某个节点的父级 level 与自身 level 差值大于 1就给它挂一个虚拟的省直辖节点作为父级名称固定、代码用约定值前端展示成某省 / 省直辖 / 某某县就行。这样做的好处是树的形状保持规整树遍历、面包屑导航这些通用逻辑都不用改。5.3 时效性层面的坑现象用户反馈说选到了一个前几年就已经撤县设区的名字而新设的区在系统里根本找不到。数据包是静态的区划调整却是动态的拿到手不更新一年之后就开始出现偏差。判断数据新不新看两处文件命名里的年份标识以及数据里最近一次区划调整是否包含在内。如果包本身没有版本号可以挑几个近年调整过的区划代码去表里查一下查不到就是旧版。解决思路是把更新做成流程而不是一次性动作。表里保留status和updated_at每次导入新版本前先跑 4.3 节的 diff 脚本生成变更清单新增的插入、撤销的置失效、更名的更新名称做到可追溯。撤销的代码永远不删历史数据还能正常展示只是在新业务里不再出现。现象多环境导入同一份脚本测试库能查到三千条线上库只查得到两千八。先比对两边的SELECT COUNT(*)再比对SELECT MAX(code)和主键最大值。差异通常来自三处导入过程中断但没报错客户端连接超时被静默 kill、脚本里带了WHERE条件的分批插入只跑了第一批、线上库有唯一索引导致部分 INSERT 被INSERT IGNORE吞掉。最后这种情况最容易忽略因为导入过程没有任何报错提示只是数据少了。稳妥的做法是导入前先DROP再CREATE导入后强制跑一遍数量校验把三条数字省级、地级、县级对齐了再切流量。6. 二次开发把静态代码表改造成可增量维护的区划服务拿到 SQL 包直接用是第一步真正省事的是包一层薄薄的接口。我一般用几十行代码起一个只读服务SQLite 做后端就够了三千条数据完全不需要上 MySQLfrom fastapi import FastAPI import sqlite3 app FastAPI() def get_conn(): conn sqlite3.connect(region.db) conn.row_factory sqlite3.Row # 让结果支持按列名访问 return conn app.get(/region/children) def children(parent: str 000000): 按父级代码查直属下级parent 传 000000 返回所有省级 with get_conn() as conn: rows conn.execute( SELECT code, name, short_name, level FROM sys_region WHERE parent_code ? AND status 1 ORDER BY code, (parent,), ).fetchall() return [dict(r) for r in rows]parent参数用查询串传递默认值000000表示根节点。SQL 用参数化写法?占位避免拼接字符串带来的注入风险虽然这里只是查表但习惯要统一。status 1这个过滤必须带上否则已撤销的区划会混进下拉框用户选了之后提交到下游系统又是一轮排查。返回值里带short_name是为了前端在窄屏下显示简称level则是给调用方判断要不要继续往下钻。在这层接口之上可以做两个改造。第一个是缓存服务启动时把全量数据读进字典按parent_code建索引后续请求直接查内存响应时间从毫秒级降到微秒级代价是改数据要重启。第二个是增量更新单独建一张region_version表记录每次导入的版本号和数据截止时间接口返回时带上version字段前端可以据此判断本地缓存要不要失效。这两个改造都不复杂但能让一份静态数据长期可用。有个习惯我保持了几年每次换新版本的 SQL 包先把新旧两份导入两个临时库跑一遍 diff 脚本把新增、撤销、更名的条数记进变更表确认没有异常大面积的变动之后才更新正式库。有一次拿到的包少了整整一个地级单位下面的所有区县数量校验直接报了红要是不做这一步线上就是几千条地址挂不上区县。从那以后我每次导入行政区划数据都强制走一遍数量校验 diff 比对 孤儿节点检查这三步一步都不敢省。希望帮到你。本文还有配套的精品资源点击获取
简介面向从事地理信息、人口统计、物流规划与数据库开发的人员这份GB/T 2260全国行政区划代码数据集提供了一套标准化的四级区划编码参考覆盖省/直辖市、市、县及乡镇街道等层级可用于搭建行政区划表、做数据匹配与地域维度分析。压缩包共4个文件包含SQL脚本、Access数据库、TXT文本和XLSX表格整体约5.01MBSQL脚本便于导入MySQL建表Access文件可脱离SQL环境直接查看TXT与XLSX则方便在Excel中筛选、核对和二次整理。数据量约46462条版本为2017年最新版能支撑人口统计、GIS、物流规划与市场分析等场景也适合作为开发测试的基础字典表。使用时需留意行政区划调整带来的时效性。目前已有1105人学习。1. 项目定位一份 GB/T 2260 行政区划代码 SQL 能省掉多少脏活做后台系统的都躲不开选省市区这个需求用户注册要选、订单要按地区统计、门店要挂行政区划编码。第一反应是找接口接口要授权、有限流、赶上对方机房抖动还得背锅第二反应是自己维护一张表于是就有了无数个从网页上扒下来再手工补的下午补完之后发现某个县级市根本不存在。这份资源解决的就是最底层那一层把 GB/T 2260 行政区划代码整理成可直接导入关系型数据库的 SQL 脚本省、地、县三级齐全字段带名称、层级、父级编码导进去就能查不用再对着标准文本一行行敲。适合做 SaaS 多租户地域配置的、做物流地址库的、做数据看板按地区聚合的以及任何不想为了选个省再引一个第三方 SDK 的团队。数据是静态的但静态恰恰是它的价值——你把它当成字典表放进自己的库主动权就在自己手上。2. 数据骨架六位编码规则与省市区建表语句怎么对应2.1 GB/T 2260 的六位编码到底怎么切行政区划代码是 6 位定长数字字符串不是整数这个细节决定了后面所有字段类型的选择。结构上分三段每段两位位段含义取值说明第 1-2 位省级01-99 之间分配用于标识省、自治区、直辖市第 3-4 位地级00表示该省直接管辖县级单位01-99 为地级市、自治州、地区第 5-6 位县级00表示该地级单位直接管辖01-99 为市辖区、县、县级市一个省级单位的代码形如900000它下辖的地级单位就是900100、900200、900300这样按顺序往后排一个地级单位的代码形如900100它下辖的区县则是900101、900102。所以严格意义上说省级代码就是后四位全是00的代码地级代码就是后两位是00的代码这个规律可以直接用来校验数据是否自洽。很多数据包里没有单独的 level 字段靠的就是这条规则现算。值得单独拎出来说的是直辖市和特殊县级单位。直辖市的省级代码下面通常不会直接挂区县而是先挂一层市辖区当作伪地级中间两位用01、02之类而省直辖的县级行政单位中间两位常见90这样的特殊段父级直接指回省级代码。这两种形态是后面查询断链的主要来源建表的时候必须留有兜底余地。解析一个代码属于哪一层写个小函数就够了def parse_code(code: str) - dict: 把 6 位行政区划代码拆成省/市/县三级 if not code or len(code) ! 6 or not code.isdigit(): raise ValueError(f非法区划代码: {code}) if code[2:] 0000: level 1 # 后四位全 0省级 elif code[4:] 00: level 2 # 后两位全 0地级 else: level 3 # 其余都是县级 return { province: code[:2] 0000, # 省级代码 city: code[:4] 00, # 地级代码 county: code, # 县级代码 level: level, }parse_code的入参必须是字符串而不是整数因为01这种省级代码一旦被当成整数解析前导零直接消失整个层级关系就废了。返回值里的province和city是向上补齐的结果拿来反查父级最方便level则用于判断这条记录该落在哪一级。另一个高频混淆点是 6 位行政区划代码和 12 位统计用区划代码的区别。后者是统计口径前 6 位与行政区划代码对齐后 6 位是居委会、村委会的标识长度和含义都不同。有人把 12 位数据直接塞进 6 位字段结果被截断得一塌糊涂。做业务地址库时用 6 位就够只有做人口普查级别的统计才需要 12 位。2.2 一张自关联表还是拆成三张表拿到 SQL 包之后第一个决策是表结构。常见三种形态各有取舍方案优点缺点适用场景单表自关联code parent_code level结构简单增删改只动一处天然支持任意层级扩展三级联动要自连接两次或用递归 CTE绝大多数业务系统拆成 province / city / county 三张表查询直观前端字段对接直白数据冗余层级调整要同时改三张表层级绝对固定、只读的展示场景单表 物化路径path 存900000/900100/900101查某节点的整棵子树一条 LIKE 搞定路径维护成本高任何父级变更都要级联更新需要频繁查下级的组织架构类系统我一般会选第一种单表自关联。理由很实在行政区划虽然看着是三级但业务上经常出现省直辖县级单位这种跨级挂载三表模型的county.city_code就得填空值查询时到处写IS NULL判断血泪经验。单表只多一个 level 字段什么形态都能容纳。对应的建表语句CREATE TABLE sys_region ( id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT COMMENT 自增主键, code CHAR(6) NOT NULL COMMENT GB/T 2260 六位行政区划代码, name VARCHAR(64) NOT NULL COMMENT 行政区划全称, short_name VARCHAR(32) DEFAULT NULL COMMENT 简称去掉省/市/县等后缀, parent_code CHAR(6) DEFAULT NULL COMMENT 父级代码省级为 000000, level TINYINT NOT NULL COMMENT 层级 1省 2市 3县, pinyin VARCHAR(64) DEFAULT NULL COMMENT 拼音全拼用于模糊检索, initial CHAR(1) DEFAULT NULL COMMENT 拼音首字母用于城市选择器索引, status TINYINT NOT NULL DEFAULT 1 COMMENT 1有效 0已撤销或合并, PRIMARY KEY (id), UNIQUE KEY uk_code (code), KEY idx_parent (parent_code), KEY idx_level_name (level, name) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COLLATEutf8mb4_general_ci COMMENT行政区划代码表;code用CHAR(6)而不是INT这是整张表最不能妥协的地方前导零丢一次就得全表重导。name给到 64 是因为确实存在长度夸张的自治州全称32 位会截断。short_name是给前端展示用的列表页放全称太挤。status字段很多数据包里没有建议自己加上区划合并撤销是常态历史订单引用的旧代码不能直接删标个失效最省心。pinyin和initial也是数据包之外的补充前端城市选择器要靠首字母索引导入后跑个脚本批量生成一次就行。uk_code唯一索引是数据质量的最后一道闸重复代码在导入阶段就该被拦下来别等到业务层查出两条同名记录再去排查。idx_parent服务于三级联动idx_level_name服务于后台按名称搜索两个索引基本覆盖日常查询。2.3 包里通常有哪些文件、各自干什么用这类资源一般会按数据库方言拆成几份常见构成是一份 MySQL 版的全量脚本包含建表语句加批量 INSERT一份 PostgreSQL 版可能用COPY语句做高速导入部分还会附一份 SQLite 文件拿到手直接能开。文件命名通常带年份或版本号方便区分数据截止时间。用之前先确认三件事建表语句里的字段类型是不是CHAR(6)、INSERT 是不是批量合并成多值形式、脚本开头有没有DROP TABLE IF EXISTS。批量 INSERT 对导入速度影响极大一条一条插几千行要跑几分钟合并成INSERT INTO ... VALUES (...),(...),(...)之后通常几秒就完。DROP TABLE存在于全量包里是正常的但如果你的库里有自己加的字段直接执行会把它们一起清掉所以正式环境导入前先看一下脚本头部把它改成CREATE TABLE IF NOT EXISTS或者先备份。3. 落库实战SQL 脚本导入、三级联动查询与索引调优3.1 三种导入姿势各自适合什么场合MySQL 场景下最直接的是命令行重定向# 指定字符集避免中文变成问号 mysql -u root -p \ --default-character-setutf8mb4 \ mydb region_gbt2260.sql--default-character-setutf8mb4这个参数不能省。客户端默认字符集如果是latin1脚本里的中文会被按错误编码解释导入完成后name字段整列都是问号或者乱码方块而且这种损坏是不可逆的只能删表重来。mydb要提前建好并确认 collation 是utf8mb4_general_ci或utf8mb4_0900_ai_ci库的字符集和客户端字符集不一致一样会出问题。如果脚本太大或者需要边导边看报错进 MySQL 交互界面用source更灵活-- 先切库再执行脚本报错会逐条打印出来 USE mydb; SET NAMES utf8mb4; SOURCE /path/to/region_gbt2260.sql;SET NAMES utf8mb4的作用和命令行参数一致只是改成在会话里设置。SOURCE后面必须是服务器能访问到的绝对路径写成相对路径经常报Failed to open file很多人卡在这一步以为是文件权限问题。PostgreSQL 和 SQLite 的处理方式略有差异。PostgreSQL 用psql -f region.sql -U user -d mydb如果脚本里是COPY ... FROM stdin的形式必须用psql执行不能走图形客户端否则会报COPY 数据必须来自标准输入。SQLite 最简单sqlite3 region.db region.sql或者进交互界面.read region.sql都行注意 SQLite 的类型系统是动态的CHAR(6)只是声明写入时不会强制截断所以导入后仍然要用 SQL 校验一遍长度。导入完先跑一条计数确认SELECT level, COUNT(*) AS cnt FROM sys_region GROUP BY level ORDER BY level;省级通常在 30 到 40 之间地级在 300 到 400 之间县级在 2800 到 3000 之间。这三个数字记在脑子里是判断数据完不完整的第一个信号。数量对不上后面所有查询都白搭。3.2 三级联动的几种写法与性能差异最朴素的做法是前端一次性拉全量后端一条 SQL 返回所有有效记录前端自己按parent_code组装成树SELECT code, name, parent_code, level FROM sys_region WHERE status 1 ORDER BY level, code;三千行左右的数据JSON 序列化后大概几百 KBgzip 之后一百多 KB首次加载拉一次存前端内存后续切换省市完全不发请求。这是最省事也最快的方案适合管理后台这种对首屏体积不敏感的场景。参数上status 1过滤掉已撤销的区划ORDER BY level, code保证返回顺序稳定前端组树时不用再排序。移动端或者接口不能返大对象时改成按需查询-- 查某个省下面所有地级单位 SELECT code, name FROM sys_region WHERE parent_code 900000 AND status 1 ORDER BY code; -- 查某个地级单位下面所有区县 SELECT code, name FROM sys_region WHERE parent_code 900100 AND status 1 ORDER BY code;这里有个坑省直辖县级单位的parent_code直接指向省级所以用第一条 SQL 查某省的下级返回结果里会混着地级市和省直辖县。前端如果无脑当成市渲染用户就会看到一个县级单位出现在市级下拉框里。解决办法是在查询里带level字段前端按 level 分流或者干脆把省直辖县挂到一个虚拟的市级节点下面。需要查整棵子树时用递归 CTEMySQL 8.0 以上和 PostgreSQL 都支持WITH RECURSIVE region_tree AS ( -- 锚点从根节点开始 SELECT code, name, parent_code, level, 1 AS depth FROM sys_region WHERE code 900000 UNION ALL -- 递归部分逐层向下找子节点 SELECT r.code, r.name, r.parent_code, r.level, t.depth 1 FROM sys_region r JOIN region_tree t ON r.parent_code t.code WHERE r.status 1 AND t.depth 5 -- 限制递归深度防止脏数据死循环 ) SELECT * FROM region_tree ORDER BY code;depth 5这个限制不是多余的。如果数据里存在 A 的父级是 B、B 的父级又是 A 这种脏数据没有深度限制的递归会一直跑下去把连接池耗干。有status过滤也一样脏数据不一定 status 不对。加上限之后最多扫五层配合code排序输出结果直接就是树的前序序列。按名称模糊搜索是另一个高频需求后台经常要让运营输入某某县直接跳转SELECT code, name, level, parent_code FROM sys_region WHERE name LIKE CONCAT(%, 关键字, %) AND status 1 LIMIT 20;LIKE前置通配符会让idx_level_name索引失效变成全表扫描。三千行的表扫一遍也就一两毫秒完全能接受但如果这张表被其他业务表 join 了几十万次就该考虑把搜索单独拆出去或者用拼音首字母做前缀匹配——输入hz命中杭州这类initial字段上的索引是能吃到的。3.3 缓存策略与查询计划确认行政区划数据是典型的读多写零缓存收益极高。我通常的做法是在应用启动时把全量数据加载进本地缓存三千条记录占内存不到 1MB之后所有查询都走内存数据库只作为持久化存储-- 只捞必要字段减小缓存对象体积 SELECT code, name, short_name, parent_code, level, initial FROM sys_region WHERE status 1;如果服务是多实例部署本地缓存各自加载一份也没问题数据量小、更新频率低不需要 Redis 那一层。真有增量更新需求时发个广播消息让各实例重载就行比引入分布式缓存简单得多。索引是否被正确使用用执行计划确认一遍最稳妥EXPLAIN SELECT code, name FROM sys_region WHERE parent_code 900000;type应该是refkey应该是idx_parentrows是几十这个量级。如果type显示ALL说明索引没走常见原因是parent_code的字符集和查询条件的字符集不一致隐式转换导致索引失效。还有一种情况是查询条件写成了parent_code 900000数字MySQL 会把字符串列转成数字比较索引同样失效这个坑很隐蔽因为 SQL 不报错只是慢。4. 数据校验怎么证明这份代码表没有缺漏、错位和过期4.1 三条 SQL 把结构问题全捞出来导入完成不等于数据可用尤其是从各种渠道流转过来的 SQL 包缺行、错位、父级指向不存在的记录都可能存在。下面三条 SQL 建议每次导入后都跑一遍-- 1. 父级不存在的孤儿节点 SELECT r.code, r.name, r.parent_code, r.level FROM sys_region r LEFT JOIN sys_region p ON r.parent_code p.code WHERE r.level 1 AND p.code IS NULL; -- 2. 代码重复 SELECT code, COUNT(*) AS cnt FROM sys_region GROUP BY code HAVING COUNT(*) 1; -- 3. 名称重复但代码不同同名不同层级需要人工确认 SELECT name, COUNT(*) AS cnt, GROUP_CONCAT(code) AS codes FROM sys_region WHERE status 1 GROUP BY name HAVING COUNT(*) 1;第一条查孤儿节点结果非空说明有记录的父级代码在表里找不到对应行这种记录在三级联动里永远显示不出来属于藏起来的脏数据。第二条靠唯一索引就能拦住但如果索引是后加的历史数据可能已经重复了。第三条不是错误跨省同名县确实存在但同一个省内出现同名同级单位就该人工看一眼了大概率是数据源拼错了。4.2 用编码规则反推层级是否自洽六位编码自带校验能力代码本身就能告诉你它该属于哪一层。用一条 SQL 把所有代码形态和 level 字段对不上的记录挑出来SELECT code, name, level, CASE WHEN SUBSTRING(code, 3, 4) 0000 THEN 1 WHEN SUBSTRING(code, 5, 2) 00 THEN 2 ELSE 3 END AS expected_level FROM sys_region WHERE level CASE WHEN SUBSTRING(code, 3, 4) 0000 THEN 1 WHEN SUBSTRING(code, 5, 2) 00 THEN 2 ELSE 3 END;expected_level完全由代码推导出来和存储的level不一致就说明这条记录有问题。常见情况是数据源把省级单位标成了 level 2或者把县级市标成了 level 2——县级市的代码后两位不是00规则上就应该是 3。这种字段错位在按 level 分组统计时会让数字看着很奇怪但对查询本身没影响所以特别容易被忽略等到做权限按层级过滤时才暴露。再补一条父级层级校验确认地级的父级必须是省级SELECT c.code, c.name, c.level, p.code AS parent_code, p.level AS parent_level FROM sys_region c JOIN sys_region p ON c.parent_code p.code WHERE c.level - p.level 1;正常情况下子级 level 永远比父级大 1。差值不等于 1 说明中间跳级了典型的是县级单位直接挂在省级下面省直辖县父级 level 是 1、子级 level 是 3差值是 2。这类记录不一定是错的但必须心里有数查询逻辑要能兜住。4.3 新旧版本比对增量到底变了什么区划调整每年都有拿到新版数据包之后别急着整表覆盖先做一次 diff 看看影响面import csv def load(path): with open(path, newline, encodingutf-8) as f: return {row[code]: row for row in csv.DictReader(f)} old load(region_old.csv) new load(region_new.csv) added new.keys() - old.keys() # 新增代码 removed old.keys() - new.keys() # 撤销代码 renamed [c for c in new.keys() old.keys() if new[c][name] ! old[c][name]] # 更名 print(f新增 {len(added)} 条撤销 {len(removed)} 条更名 {len(renamed)} 条) for c in sorted(added)[:20]: print(, c, new[c][name]) for c in sorted(removed)[:20]: print(-, c, old[c][name]) for c in sorted(renamed)[:20]: print(~, c, f{old[c][name]} - {new[c][name]})load函数把 CSV 读成以 code 为键的字典两个字典做集合运算就能拿到三类变更。只打印前 20 条是为了看趋势真实场景里应该把完整清单落成一张region_change_log表记录变更时间、变更类型、变更前后名称。有了这张表历史订单里的旧代码在展示时可以查一张映射表还原成新名称不用去猜。撤销的代码不要物理删除把status置 0 就够了删掉之后再想追溯就真的没有后悔药了。5. 避坑排查行政区划数据落地最容易翻车的五件事5.1 编码与字符集层面的坑现象导入完成后name字段整列是问号或者中文变成一堆看不懂的方块。原因基本是两个一是mysql客户端默认字符集不是utf8mb4脚本里的 UTF-8 字节被按 latin1 解释后存进库二是库或表的 collation 设成了latin1_swedish_ci即使客户端对了落盘时也会被转一次。这两种损坏都不可逆改字符集不会把已有数据修好。解决方式是在导入命令里显式带上--default-character-setutf8mb4并且提前确认SHOW CREATE DATABASE mydb输出的字符集是utf8mb4。已经导入坏了的表只能TRUNCATE之后重来所以在导入前养成先建库、先查字符集的习惯比事后修数据便宜得多。现象导出的 CSV 用 Excel 打开省级代码01变成1再存回去就丢了前导零。这是 Excel 把纯数字列当成数值类型处理的经典行为跟 SQL 无关。字段本身是CHAR(6)库里存的是对的问题出在导出-编辑-再导入这条链路上。解决方式是导出时给代码列强制加文本格式或者在 CSV 里用制表符前缀如果一定要用 Excel 做人工核对把该列格式先设成文本再粘贴数据别直接双击打开。5.2 层级结构层面的坑现象某直辖市的区县在三级联动里选不出来市级下拉框是空的。直辖市下面有一层市辖区作为伪地级区县的真实parent_code指向的是这个伪地级而不是省级代码。如果前端逻辑是选中省之后按省级代码查子节点查到的只有伪地级这一条再往下就断了。解决方式有两种一是查询时把 level 的判断放宽省级节点的子节点同时兼容parent_code 省代码和parent_code IN (该省下所有市级代码)二是在数据层做一次归一化插入时把直辖市的区县parent_code直接改写成省级代码同时把city字段另存到一个city_code列里保留原始信息。我一般选第二种SQL 里多写一次 UPDATE前端逻辑就能保持统一不用到处写特殊判断。现象省直辖县级单位成了孤儿任何一级下拉框都找不到它。这类单位的parent_code指向省级代码但它自己的 level 是 3中间那一层不存在。前端的省-市-县三段式联动天然容不下这种跨级挂载。解决办法是在构建树的时候做一次兜底如果某个节点的父级 level 与自身 level 差值大于 1就给它挂一个虚拟的省直辖节点作为父级名称固定、代码用约定值前端展示成某省 / 省直辖 / 某某县就行。这样做的好处是树的形状保持规整树遍历、面包屑导航这些通用逻辑都不用改。5.3 时效性层面的坑现象用户反馈说选到了一个前几年就已经撤县设区的名字而新设的区在系统里根本找不到。数据包是静态的区划调整却是动态的拿到手不更新一年之后就开始出现偏差。判断数据新不新看两处文件命名里的年份标识以及数据里最近一次区划调整是否包含在内。如果包本身没有版本号可以挑几个近年调整过的区划代码去表里查一下查不到就是旧版。解决思路是把更新做成流程而不是一次性动作。表里保留status和updated_at每次导入新版本前先跑 4.3 节的 diff 脚本生成变更清单新增的插入、撤销的置失效、更名的更新名称做到可追溯。撤销的代码永远不删历史数据还能正常展示只是在新业务里不再出现。现象多环境导入同一份脚本测试库能查到三千条线上库只查得到两千八。先比对两边的SELECT COUNT(*)再比对SELECT MAX(code)和主键最大值。差异通常来自三处导入过程中断但没报错客户端连接超时被静默 kill、脚本里带了WHERE条件的分批插入只跑了第一批、线上库有唯一索引导致部分 INSERT 被INSERT IGNORE吞掉。最后这种情况最容易忽略因为导入过程没有任何报错提示只是数据少了。稳妥的做法是导入前先DROP再CREATE导入后强制跑一遍数量校验把三条数字省级、地级、县级对齐了再切流量。6. 二次开发把静态代码表改造成可增量维护的区划服务拿到 SQL 包直接用是第一步真正省事的是包一层薄薄的接口。我一般用几十行代码起一个只读服务SQLite 做后端就够了三千条数据完全不需要上 MySQLfrom fastapi import FastAPI import sqlite3 app FastAPI() def get_conn(): conn sqlite3.connect(region.db) conn.row_factory sqlite3.Row # 让结果支持按列名访问 return conn app.get(/region/children) def children(parent: str 000000): 按父级代码查直属下级parent 传 000000 返回所有省级 with get_conn() as conn: rows conn.execute( SELECT code, name, short_name, level FROM sys_region WHERE parent_code ? AND status 1 ORDER BY code, (parent,), ).fetchall() return [dict(r) for r in rows]parent参数用查询串传递默认值000000表示根节点。SQL 用参数化写法?占位避免拼接字符串带来的注入风险虽然这里只是查表但习惯要统一。status 1这个过滤必须带上否则已撤销的区划会混进下拉框用户选了之后提交到下游系统又是一轮排查。返回值里带short_name是为了前端在窄屏下显示简称level则是给调用方判断要不要继续往下钻。在这层接口之上可以做两个改造。第一个是缓存服务启动时把全量数据读进字典按parent_code建索引后续请求直接查内存响应时间从毫秒级降到微秒级代价是改数据要重启。第二个是增量更新单独建一张region_version表记录每次导入的版本号和数据截止时间接口返回时带上version字段前端可以据此判断本地缓存要不要失效。这两个改造都不复杂但能让一份静态数据长期可用。有个习惯我保持了几年每次换新版本的 SQL 包先把新旧两份导入两个临时库跑一遍 diff 脚本把新增、撤销、更名的条数记进变更表确认没有异常大面积的变动之后才更新正式库。有一次拿到的包少了整整一个地级单位下面的所有区县数量校验直接报了红要是不做这一步线上就是几千条地址挂不上区县。从那以后我每次导入行政区划数据都强制走一遍数量校验 diff 比对 孤儿节点检查这三步一步都不敢省。希望帮到你。本文还有配套的精品资源点击获取
