全国四级行政区划底表：adcode、邮编与经纬度落库实践

简介面向地理信息系统开发、物流配送与地图服务等场景整理的中国行政区划邮编及经纬度数据表覆盖省、市、区、县、乡、镇、街道层级可用于地址检索、区域划分、路径规划与空间分析等基础工作。压缩包共1个文件为SQL脚本格式体积约942KB导入数据库后即可按行政层级查询对应邮政编码与经纬度字段便于快速搭建测试环境或作为业务系统的基础数据源。已有796人学习说明其在GIS入门与地址数据整理方面具有一定参考价值。数据以表结构组织字段包含省份、城市、区县、乡镇、街道、邮编及经纬度适合开发者直接筛选、关联和二次加工也能为市场分析、政府规划与灾害响应等应用提供位置底表减少自行采集与清洗行政区划坐标的成本。1. 邮编与经纬度坐标底表把「省-市-区县-乡镇街道」四级串成一棵树上个月有个做本地生活调度的朋友拿着他们的地址库来问两万多个门店按街道归属分单有三成落到隔壁镇去了。翻了一下地址表只到区县一级街道那列是运营手工填的同名街道一多全乱。问题不在代码逻辑在地基——缺一张带层级关系的行政区划底表把省、市、区县、乡镇街道串成树同时给出对应的邮政编码和经纬度坐标。这份资源就是干这个的全国四级行政区划的编码、名称、邮政编码、经纬度坐标一份能直接落进数据库的静态底表。做 CRM 地址校验、物流分单、门店圈选、报表地图下钻、开票地址补全的都能拿它当底座。它不是实时接口是离线表好处是不依赖网络、不怕限流、能随意 JOIN代价是行政区划本身会变撤县设区、乡改镇、街道拆分年年有得自己养一套更新机制。下面按我实际落库的顺序拆。2. 读懂表结构与 adcode 编码层级树为什么不能靠 name 拼拿到表第一件事不是急着导入是先搞清楚每一列代表什么粒度。这份数据的价值有八成在编码体系上看不懂编码后面全是字符串匹配的玄学。2.1 字段清单与四级层级设计全国行政区划在数据里通常按四级组织省级省、自治区、直辖市、地级地级市、地区、自治州、盟、县级市辖区、县、县级市、旗、乡级镇、乡、街道、苏木。再往下还有村级但村级的区划代码和邮编变动极快绝大多数业务到乡级就够了这份资源也是止步于乡级。一份合格的底表至少要有这几列字段含义典型取值注意事项adcode行政区划代码6 位或 9 位数字串必须按字符串存前导零不能丢parent_code上级区划代码同 adcode 格式顶级为 0 或空全表统一name区划名称纯名称不带上级前缀会重名不能当唯一键level层级province/city/district/town用整数 1-4 更好排序postcode邮政编码6 位数字乡级可能为空lng / lat经度 / 纬度十进制度float注意坐标系见第 4 章full_name全路径名省市区街道冗余字段为的是省一次递归最容易翻车的是adcode。它长得像数字但本质是标识符不是数值。存成 int 之后前导零的地方直接掉位跟父级对不上整棵树断成好几截。我第一次导的时候就吃了这个亏parent_code用 int 存匹配率只有七成多剩下一堆孤儿节点。2.2 adcode 与 parent_code 构成的树adcode 的编码规则不是随机的前 2 位是省级前 4 位是地级前 6 位是县级第 7 到 9 位是乡级。这意味着即使parent_code列丢了或者有脏数据理论上也能靠前缀反推父级。但实际数据里省级直辖的县级单位、省直管市这类特殊层级前缀反推会出错所以parent_code必须是权威字段前缀只用来做校验。导入前我会先跑一遍结构体检把孤儿节点、环、重复键全揪出来import pandas as pd # 全部按字符串读dtype 显式指定避免 pandas 自作主张把 adcode 转成 int df pd.read_csv(region.csv, dtype{ adcode: str, parent_code: str, name: str, level: int, postcode: str, lng: float, lat: float, }) # 1. 主键唯一性 dup df[df.duplicated(adcode, keepFalse)] print(重复 adcode 行数:, len(dup)) # 2. 孤儿节点parent_code 在表里找不到顶级节点除外 codes set(df[adcode]) orphan df[(df[parent_code].notna()) (~df[parent_code].isin(codes))] print(孤儿节点:, len(orphan)) print(orphan[[adcode, name, parent_code, level]].head(20)) # 3. 层级校验子节点 level 应比父节点大 1 lv df.set_index(adcode)[level].to_dict() bad_level df[df[parent_code].map(lv).notna() (df[level] ! df[parent_code].map(lv) 1)] print(层级不连续:, len(bad_level)) # 4. 前缀一致性校验仅做提示不作强约束 def prefix_ok(row): p, c row[parent_code], row[adcode] if not isinstance(p, str) or p in (0, ): return True return c.startswith(p[:len(p)]) print(前缀不一致:, (~df.apply(prefix_ok, axis1)).sum())这段代码的逻辑是四道闸门唯一性保证不会有两条同码记录孤儿检测保证树的连通性层级校验保证 level 和父子关系自洽前缀一致性只做提示。参数上关键是dtype全部显式声明为str这是整段代码里最不能省的一行parent_code的顶级标识要跟你手上的数据对齐有的是0有的是空字符串有的是100000先df[parent_code].value_counts().head()看一眼再写判断。如果孤儿节点数量在几十条以内大概率是新增区划导致的父子版本错位人工比对一下就能补如果上千条多半是编码被截断或者编码列混进了全角字符先查数据源不要急着写脚本修补。2.3 邮编字段的粒度和空缺规律邮政编码这块要有心理准备它不是每个乡级单位都有。国内的邮政编码体系是六位前两位定省、第三位定邮区、第四位定县、最后两位定投递局而投递局的设置跟行政区划不是一一对应的。现实中大量乡镇街道共用同一个县级邮编偏远乡镇、开发区、新建街道经常是空的。所以邮编列拿到手后先做一次覆盖率统计按层级分组cov df.groupby(level).agg( total(adcode, size), has_pc(postcode, lambda s: s.notna().sum()), ) cov[覆盖率] (cov[has_pc] / cov[total] * 100).round(1) print(cov)跑完你会看到省级、地级、县级覆盖率接近 100%乡级会明显掉下来。这个结果决定了后面的使用策略邮编只做到县级可信乡级邮编当参考值用。业务上如果要求「街道级邮编必填」就不要从这份表直接取得走「乡级为空则回填县级邮编」的降级逻辑并在返回结果里带一个postcode_level字段标明来源层级——这个字段在排查客诉的时候能救命。3. 落库与索引把地址查询压到毫秒的建表方案数据量不大全国四级区划加起来几千到几万行的量级任何数据库都能一口吞下。真正决定性能的不是数据量是索引和查询写法。3.1 MySQL 建表与联合索引我一般这么建字段类型和索引一次性到位CREATE TABLE region ( id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT, adcode VARCHAR(12) NOT NULL COMMENT 行政区划代码字符串存保留前导零, parent_code VARCHAR(12) NOT NULL DEFAULT 0, name VARCHAR(64) NOT NULL, full_name VARCHAR(255) NOT NULL DEFAULT COMMENT 省市区街道全路径, level TINYINT UNSIGNED NOT NULL COMMENT 1省 2市 3区县 4乡镇街道, postcode VARCHAR(6) DEFAULT NULL, lng DECIMAL(10,6) DEFAULT NULL COMMENT 经度6位小数约0.1米精度, lat DECIMAL(10,6) DEFAULT NULL, PRIMARY KEY (id), UNIQUE KEY uk_adcode (adcode), KEY idx_parent (parent_code), KEY idx_level_name (level, name), KEY idx_postcode (postcode), KEY idx_lnglat (lng, lat) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;几个参数值得说adcode用VARCHAR(12)而不是CHAR(6)是因为有的数据源乡级码是 9 位甚至 12 位留余量比后期改表便宜lng/lat用DECIMAL(10,6)而不是FLOAT六位小数对应约 0.1 米全国范围绝对够用而且DECIMAL做等值比较不会有浮点误差idx_level_name是给「某层级按名称模糊查」准备的level在前是因为选择性低但过滤量大能先把范围砍掉四分之三。批量导入用LOAD DATA LOCAL INFILE几万行秒级完成。导入前把local_infile打开CSV 里 NULL 用\N表示空字符串和 NULL 要区分清楚——邮编列的空值必须是 NULL写成空字符串会让「是否有邮编」的判断失效。LOAD DATA LOCAL INFILE /tmp/region.csv INTO TABLE region FIELDS TERMINATED BY , OPTIONALLY ENCLOSED BY LINES TERMINATED BY \n IGNORE 1 LINES (adcode, parent_code, name, full_name, level, postcode, lng, lat);IGNORE 1 LINES跳过表头FIELDS TERMINATED BY ,后面那串OPTIONALLY ENCLOSED BY 是必须的因为区划名称里会出现带逗号或引号的情况少见但一出现整行就会错位而且报错信息极其难懂。3.2 递归 CTE 拼全路径full_name这个冗余字段是为了省一次递归。如果数据源没给用 MySQL 8 的递归 CTE 一次性补齐UPDATE region r JOIN ( WITH RECURSIVE tree AS ( -- 锚点所有省级节点路径初始化为自身名称 SELECT adcode, parent_code, name, CAST(name AS CHAR(255)) AS path, 1 AS lv FROM region WHERE level 1 UNION ALL -- 递归把子节点拼到父节点路径后面 SELECT c.adcode, c.parent_code, c.name, CONCAT(t.path, /, c.name), t.lv 1 FROM region c JOIN tree t ON c.parent_code t.adcode WHERE t.lv 4 ) SELECT adcode, path FROM tree ) x ON r.adcode x.adcode SET r.full_name x.path;递归的锚点是level 1lv 4是防止脏数据成环导致无限递归——这一步不加只要有一个节点的parent_code指向自己的子孙这条 SQL 就会一直跑到max_recursion_depth报错。CAST(name AS CHAR(255))是必须的MySQL 递归 CTE 里字符串列宽默认继承锚点不显式放大拼到第三层就截断了。拼完之后full_name形如某省/某市/某区/某街道做前端展示、导出报表、日志打点都很方便但查询匹配不要用 full_name 做 LIKE 右模糊那是全表扫描。正确做法是按level name索引先定位再顺着parent_code向上或向下走。3.3 SQLite 的轻量替代方案如果只是做离线工具、桌面应用或者数据清洗脚本没必要上 MySQL。SQLite 同一份建表语句基本能跑改两处AUTO_INCREMENT换成AUTOINCREMENTDECIMAL会退化成浮点存储但区划坐标这个精度无所谓。索引照建PRAGMA journal_mode WAL打开批量插入包在一个事务里几万行导入在一秒内。import sqlite3, pandas as pd conn sqlite3.connect(region.db) conn.execute(PRAGMA journal_modeWAL) df pd.read_csv(region.csv, dtype{adcode: str, parent_code: str, postcode: str}) with conn: # 上下文管理器自动开事务失败整体回滚 df.to_sql(region, conn, if_existsreplace, indexFalse) conn.execute(CREATE UNIQUE INDEX uk_adcode ON region(adcode)) conn.execute(CREATE INDEX idx_parent ON region(parent_code))with conn:这个写法很多人不知道它会自动提交或回滚比手动commit()安全。if_existsreplace在反复调试时很方便但上生产前记得改成append配增量逻辑否则一次误跑就把全表冲了。4. 坐标系与就近检索GCJ-02 和 WGS84 到底差多少米坐标这一列是整个资源里最容易出错的部分也是最难自查的部分——你看到的数字都合法误差却藏在几百米开外。4.1 坐标系识别三种常见基准的偏移量国内流通的坐标基本就三种WGS84GPS 原始输出、国际标准、GCJ-02国内地图服务的基础坐标、BD-09在某一种基础坐标上再叠加一次非线性偏移。三者之间的转换不是简单的加减常数是非线性的只能在局部近似。实操中的判断方法拿一个你确定位置的地标比如某个已知坐标的园区大门分别转成三种坐标去比对偏差最小的那个就是数据源用的基准。经验值上同一点在 GCJ-02 和 WGS84 之间的差通常在几十米到几百米BD-09 相对 GCJ-02 还有一次偏移量级类似。城市越大、纬度越高偏差表现越不一样别指望记住一个固定数字。一个更省事的办法是看数据来源。从某地图开放平台导出的九成是 GCJ-02从 GPS 设备、测绘报告、国际开源数据来的基本是 WGS84从某些搜索引擎地图复制来的大概率 BD-09。整份表必须统一到一种基准混着存就是灾难——同一批门店一半偏北一半偏东你连调试都无从下手。落库时建议加一列coord_sys值域限定为WGS84 / GCJ02 / BD09转换的脚本单独放转完写回并打标记永远不要在原列上原地改。这是后悔药丢了就找不回来。4.2 边界框预筛 Haversine 排序「找出我附近 5 公里的所有街道」这种需求直接用距离公式全表扫几万行还行量级上去就废了。标准做法是先用经纬度边界框把候选集砍到几百行再算精确距离import math R 6371000.0 # 地球平均半径米 def haversine(lat1, lng1, lat2, lng2): 返回两点间大圆距离米。入参均为十进制度。 p1, p2 math.radians(lat1), math.radians(lat2) dp p2 - p1 dl math.radians(lng2 - lng1) a math.sin(dp / 2) ** 2 math.cos(p1) * math.cos(p2) * math.sin(dl / 2) ** 2 return 2 * R * math.asin(math.sqrt(a)) def nearby(conn, lat, lng, radius_m, limit20): # 1 度纬度约 111km经度方向要乘 cos(lat) 修正 dlat radius_m / 111000.0 dlng radius_m / (111000.0 * math.cos(math.radians(lat))) # 先走 idx_lnglat 复合索引做范围扫描把候选集压到极小 rows conn.execute( SELECT adcode, name, full_name, postcode, lng, lat FROM region WHERE level 4 AND lat BETWEEN ? AND ? AND lng BETWEEN ? AND ? , (lat - dlat, lat dlat, lng - dlng, lng dlng)).fetchall() out [] for r in rows: d haversine(lat, lng, r[5], r[4]) if d radius_m: out.append((*r, round(d, 1))) out.sort(keylambda x: x[-1]) return out[:limit]逻辑分两段边界框负责粗筛lat BETWEEN ... AND lng BETWEEN ...能命中idx_lnglat复合索引把几万行砍到几十行Haversine 负责精算返回真实距离。参数上R 6371000是米制111000.0是 1 度纬度的近似米数更精确是 111320差 0.3%对 5 公里半径影响在 15 米内可以接受dlng里那个cos(lat)千万别漏高纬度地区漏掉这一项横向搜索范围会严重偏大。返回结果里带上距离业务侧可以直接拿来排序和展示。如果对性能要求更高MySQL 8 可以上POINT类型加SPATIAL INDEX但注意SRID 4326的距离计算返回的是度不是米还得自己换我一般懒得折腾边界框方案已经足够。4.3 行政中心点不是辖区范围这是使用这类数据时最容易产生的误解表里的经纬度是行政中心点通常落在政府驻地或者几何中心不是辖区的面。拿它算「某坐标属于哪个区」只能是「离哪个中心点最近」不等于「落在哪个辖区内」。真实场景里这会出问题两个区交界处的一条街距离 A 区中心 800 米、B 区中心 900 米按中心点判断归 A 区实际归属可能是 B 区。做圈选、分单、配送范围这类业务如果边界精度要求高必须另外拿一份带面几何的边界数据用点在多边形算法判定。中心点坐标的定位是「快速近似 默认值」不是「精确判定」。提示业务上凡是用到中心点坐标做归属判断的地方都在返回结果里标一个is_approx标记。产品经理看到这个字段就不会在客诉时问你「为什么这单派错了」。5. 避坑与排查五条踩过的血泪记录这一章是全篇最值钱的部分都是我在不同项目里真实翻过的车按现象、原因、解决三段写能对号入座就直接抄。5.1 编码与唯一性相关的两个坑坑一adcode 前导零丢失树断成几截。现象导入后parent_code匹配率只有七成多大量节点成了孤儿full_name拼出来只有两级甚至一级。原因用 Excel 打开 CSV 再另存或者用 pandas 默认参数读取adcode被当成数值型开头的 0 被吃掉。省级和部分地级码开头不是 0 所以看着正常县级和乡级大量掉位。解决数据源永远不要经过 Excel 中转读取时显式dtype{adcode: str, parent_code: str}入库后跑一次SELECT COUNT(*) FROM region WHERE CHAR_LENGTH(adcode) NOT IN (6,9,12)非零就说明还有问题。补零要用LPAD按层级补齐不要无脑补到 6 位乡级 9 位的会被补错。坑二用 name 做关联同名乡镇全串了。现象按名称 JOIN 或WHERE name 某镇查询返回好几条业务侧随机取第一条导致地址分布图上出现明显错位。原因乡镇街道级的重名率非常高同一个地级市下面有两个同名镇是常态跨省重名更是海量。name在这一层完全不唯一。解决所有关联一律走adcodename只用于展示和模糊搜索必须按名称查的时候强制带parent_code或full_name前缀。给name建索引可以但索引名里别叫uk_name免得后人误以为是唯一键。5.2 坐标与距离相关的两个坑坑三坐标系混用距离算出来差一倍。现象就近检索返回的结果肉眼可见地偏做了个门店到街道的距离分布图出现了几百公里的离群点。原因部分坐标来自某地图服务商GCJ-02部分来自 GPS 设备WGS84混在一张表里。两种基准在城市区域偏差几百米做距离排序时排名整个乱掉做半径过滤时边界附近全乱。解决先做基准识别全表统一到一种加coord_sys列记录来源转换脚本独立、可重跑、幂等。校验方法是抽 20 个点转回原基准误差应小于 1 米超了就是转换公式写错。坑四边界框漏了 cos 修正高纬度地区搜不到。现象同一个检索接口低纬度城市返回正常北方某些城市返回空结果或者数量明显偏少。原因dlng radius / 111000没乘cos(lat)经度方向的搜索窗口被高估了——等等这里是反的。实际是乘了cos(lat)之后窗口变窄如果不乘窗口偏大不会漏漏的原因是有些实现把dlng算反了或者把经纬度参数顺序传反了。解决函数签名里强制写lat, lng顺序并在函数内第一行加断言-90 lat 90 and -180 lng 180。更狠一点直接拒绝lng落在[-90, 90]之外但lat在其内的入参因为那大概率是传反了——国内经度都在 70 以上纬度都在 55 以下这个断言几乎不会误伤。5.3 区划变更导致的历史数据错位坑五撤县设区之后老 adcode 查不到人。现象历史订单里存的 adcode 在最新底表里查不到前端地址回显空白客服系统点进去一片白。原因行政区划调整是常态撤县设区、乡改镇、街道拆分合并、开发区代管都会产生新代码、废弃旧代码。底表更新之后历史数据里的旧码就成了孤儿。解决底表不做物理删除废弃记录保留并标记status deprecated同时维护一张adcode_mapping表记录old_code → new_code的映射关系。查询时先走新表命中不了再查映射表最后兜底用历史快照。这套机制建立起来要半天不建的话每次区划调整都要人工修数据那才是真血泪。注意区划调整每年都有别指望一次导入用三年。更新频率建议是季度拉一次全量比对见下一章的增量方案。6. 增量更新与地址归一化把静态底表养成活数据静态底表最大的风险不是数据错是过期。我在某个项目上吃过一次亏底表是两年前导的期间一个县级市改了名一个区被拆分结果他们的开票系统连续三个月给客户开出错误的行政区划名称财务对账时才被发现。从那以后我每次接这类数据第一件事就是建增量比对流程而不是直接LOAD DATA完事。增量比对的核心思路很简单拉一份新全量跟库里做差集分三类处理。import pandas as pd new pd.read_csv(region_new.csv, dtype{adcode: str, parent_code: str}) conn sqlite3.connect(region.db) old pd.read_sql(SELECT adcode, name, parent_code, level, postcode FROM region, conn) # 集合运算得到三类变更 added set(new.adcode) - set(old.adcode) # 新增区划 removed set(old.adcode) - set(new.adcode) # 撤销/合并 common set(new.adcode) set(old.adcode) # 存量需比对字段 o old.set_index(adcode); n new.set_index(adcode) changed [] for code in common: for col in [name, parent_code, level, postcode]: if str(o.at[code, col]) ! str(n.at[code, col]): changed.append((code, col, o.at[code, col], n.at[code, col])) print(f新增 {len(added)} / 撤销 {len(removed)} / 字段变更 {len(changed)}) pd.DataFrame(changed, columns[adcode,字段,旧值,新值]).to_csv(diff.csv, indexFalse)这里的关键参数是对比字段的范围name变了要做映射表parent_code变了意味着整个子树的full_name全部失效必须重算postcode变了相对无害但也要记录。removed集合不要直接删写进deprecated表保留至少两个版本周期。changed输出成 CSV 人工过一遍通常每季度也就几十条十分钟能看完。地址归一化是这份数据最实用的延伸用法。用户填的地址是自由文本先做省市区县的正则切分和简称还原「某省」简称与全称映射、地级市省略后缀把能识别的部分匹配到adcode剩下街道部分在该区县的下级节点里做编辑距离匹配取相似度最高且超过阈值的。匹配结果势必有歧义所以一定返回候选列表加置信度别做成单值覆盖——用户填「某路 12 号」你给他强行归到某个街道出了问题比不归更麻烦。几个我固定会做的验证动作导入后跑一遍记录数按层级的分布跟上一版比某一级数量突变超过 5% 就要查原因抽查 30 个随机 adcode 的全路径拼接是否正确用一批已知坐标做就近检索看返回的街道名是否符合预期最后把postcode为空的乡级记录单独导一份业务侧确认这些能不能接受回填县级邮编。这套动作我每次更新都强制走一遍快的话二十分钟省下的都是后面的扯皮时间。这份数据的价值不在数据本身在你能不能把它变成一张有人维护、有版本、有映射关系的活表。希望帮到你。本文还有配套的精品资源点击获取