简介这份资源是面向后端开发、数据分析与地理信息系统开发者的MySQL行政区划数据脚本用于快速构建中国省份、城市及区县的层级化数据表解决应用中地域信息存储与关联查询的基础需求。压缩包内共1个SQL文件整体约69KB文件为建表与数据填充脚本可直接导入MySQL执行省去手工整理行政区划数据的繁琐过程。资源围绕t_area.sql展开表结构通常包含主键id、省份、城市、区县、行政区域编码、层级标识及父级ID等字段通过parent_id串联省市区层级便于使用JOIN或递归查询获取完整行政链也可与人口、公司地址等业务表联合使用。目前已有638人学习下载适合需要快速落地地域选择、物流地址、统计报表等场景的开发者参考使用。1. 一份 t_area.sql 能省掉多少事从省市区三级联动说起做过电商收货地址、物流分单、门店区域归属的人都知道省市区数据这东西第一次接的时候觉得简单真动手才发现是个体力活。要么去某个开放平台调接口要么自己对着行政区划表一条条录前者受网络和配额限制后者纯属折磨。我手上这份「全国省份城市数据库表mysql.zip」就是干这个的——解压出来一个t_area.sql导入 MySQL 之后直接得到一张带层级关系的行政区划表省、市、区县三级用parent_id串起来还带国标行政编码。它适合谁适合正在做地址选择器、运费模板、区域报表又不想在基础数据上耗时间的后端和全栈。下面我按「先看懂表结构再导入再查询最后避坑」的顺序拆一遍你照着敲就能跑起来。2. 先看懂 t_area.sql 的表结构字段、层级与编码怎么设计2.1 一张自关联表撑起三级行政区划这类脚本的典型设计是一张自关联self-referencing表而不是省、市、区三张独立表。为什么因为三张表意味着三次 JOIN 才能拿到「省-市-区」完整链路而自关联表用parent_id指向上级一次递归或者几次自连接就能拼出层级。常见字段大致是这样字段类型含义说明idint / bigint主键自增程序内部关联用parent_idint父级 ID顶级省份为 0 或 NULLnamevarchar名称省 / 市 / 区县名codechar(6) / varchar行政编码国标 6 位如 110000leveltinyint层级1 省、2 市、3 区县pinyin / initialvarchar拼音 / 首字母部分脚本带用于索引排序拿到脚本先别急着导入用编辑器打开扫一眼CREATE TABLE段确认三件事主键是不是自增、parent_id默认值是什么、code字段长度够不够。我见过有的脚本code只给了char(4)导入到一半报截断血泪经验就是先看 DDL 再执行。2.2 层级关系靠 parent_id不靠名称拼接新手容易犯的错是拿名称去拼层级比如「广东省广州市」靠字符串前缀匹配。这在实际业务里非常脆——重名、简称、别名一多就翻车。正确姿势是全程用id和parent_id走。举个查询想拿某个市下面所有区县只要WHERE parent_id 该市id想反查某个区县属于哪个省就顺着parent_id往上找两级。这种结构对索引友好也方便做缓存。提示导入前先确认脚本用的是utf8mb4还是utf8。行政区划里有生僻字utf8三字节在某些排序规则下会出问题建议统一utf8mb4。2.3 行政编码 code 的用途和坑code是国标 6 位行政区划代码前两位是省中间两位是市后两位是区县。它的价值在于跨系统对齐——对接第三方物流、税务、统计接口时对方认的往往是 code 而不是你自增的 id。但要注意行政区划会调整某个区可能被撤销或合并code 随之变化。所以如果你的业务对 code 敏感别把它当永久主键用自增 id 做内部关联code 只做外部映射。3. 导入 MySQL 的完整流程命令行、客户端与字符集设置3.1 建库建表再导入别直接 source最稳的流程是先建一个独立库再导入脚本避免污染现有库。命令行操作如下# 1. 登录 MySQL mysql -u root -p # 2. 建一个专用库字符集跟脚本保持一致 CREATE DATABASE area_db DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; # 3. 切库 USE area_db; # 4. 导入脚本在 MySQL 交互界面里执行注意路径用绝对路径 source /your/path/t_area.sql;如果你不想进交互界面也可以直接在系统 shell 里一条命令搞定mysql -u root -p area_db /your/path/t_area.sql逻辑说明source是在 MySQL 客户端内部执行文件适合已经登录的场景重定向是 shell 层面把文件喂给客户端适合脚本化。参数上-u是用户名-p后面不要跟密码会明文留在历史里回车后再输入。导入完成后用SHOW TABLES;确认表建出来了。3.2 用客户端工具导入时的字符集陷阱Navicat、DBeaver 这类图形工具导入 SQL 文件很方便但字符集设置不对就会出乱码。以常见客户端为例导入前要做两件事一是把连接字符集设成utf8mb4二是确认脚本文件本身的编码是 UTF-8 无 BOM。如果导入后发现省份名变成问号八成是连接字符集用了latin1。补救办法是重新导入别想着事后UPDATE修成本更高。-- 导入后立刻验证字符集和条数 SELECT COUNT(*) FROM t_area; SELECT * FROM t_area WHERE level 1 LIMIT 5;COUNT(*)用来确认数据量是否符合预期省级通常 30 多条含港澳台level 1过滤出省份看名称是否正常显示。这两步花不了十秒但能帮你早发现字符集问题。3.3 导入失败时的排查顺序导入报错别慌按这个顺序查第一看报错行号多半是某条INSERT的字段数对不上第二确认目标库字符集第三检查脚本里有没有DROP TABLE IF EXISTS有的话说明它会覆盖同名表别在正式库上直接跑。常见报错ERROR 1366 (HY000): Incorrect string value基本就是字符集问题ERROR 1064是语法问题通常是脚本被编辑器改过编码。4. 查询与索引优化三级联动、递归查询和常用 SQL4.1 三级联动查询怎么写才不慢前端省市区三级联动本质是三次按parent_id查询。最朴素的做法是每次用户选择都查一次库-- 查所有省份 SELECT id, name FROM t_area WHERE parent_id 0 AND level 1; -- 根据省 id 查市 SELECT id, name FROM t_area WHERE parent_id ? AND level 2; -- 根据市 id 查区县 SELECT id, name FROM t_area WHERE parent_id ? AND level 3;逻辑说明parent_id 0是顶级省份的约定有的脚本用 NULL导入后先SELECT DISTINCT parent_id FROM t_area ORDER BY parent_id LIMIT 5;确认一下。level条件是可选的冗余校验加上更保险。参数?是占位符实际用预处理语句传值别拼字符串。4.2 给 parent_id 和 code 建索引上面三条查询如果没索引数据量上万后每次联动都全表扫体验会很差。建索引很简单-- parent_id 是联动查询的核心过滤字段 CREATE INDEX idx_parent ON t_area (parent_id); -- code 用于外部系统对齐也常被查 CREATE INDEX idx_code ON t_area (code); -- 如果经常按名称搜索可以加前缀索引 CREATE INDEX idx_name ON t_area (name(10));参数说明idx_parent让WHERE parent_id ?走索引idx_code服务外部对接name(10)是前缀索引只取前 10 个字符建索引省空间适合模糊搜索场景。注意别给level单独建索引区分度太低优化器多半不用。4.3 用自连接拼出「省-市-区」完整链路有时候报表需要一行显示完整地址用两次自连接就能拼出来SELECT p.name AS province, c.name AS city, d.name AS district FROM t_area d JOIN t_area c ON d.parent_id c.id JOIN t_area p ON c.parent_id p.id WHERE d.level 3 LIMIT 10;逻辑说明以区县d为起点往上 JOIN 出市c再往上 JOIN 出省p。这种写法在数据量不大时够用但如果要查某个省下所有区县自连接会比递归更直观。MySQL 8.0 以上还支持 CTE 递归写法更优雅但兼容性要考虑——如果你的环境还是 5.7就老老实实用自连接。5. 避坑与常见问题导入、编码、层级那些翻车现场5.1 导入后中文全是问号现象SELECT出来省份名显示???或乱码。原因连接字符集或库字符集不是utf8mb4脚本里的中文按错误编码写入。解决删库重建建库时显式指定DEFAULT CHARACTER SET utf8mb4导入命令加--default-character-setutf8mb4图形工具里把连接编码也改成utf8mb4然后重新导入。别试图用CONVERT修数据已经错了修不回来。5.2 parent_id 顶级值到底是 0 还是 NULL现象查省份查不出来WHERE parent_id 0返回空。原因不同脚本对顶级节点的约定不一样有的用 0有的用 NULL。解决导入后先跑SELECT id, name, parent_id FROM t_area WHERE level 1 LIMIT 3;看一眼实际值再决定查询条件。如果混用可以在应用层统一成 0或者查询时写WHERE parent_id 0 OR parent_id IS NULL。5.3 行政区划更新导致 code 对不上现象对接第三方接口时某个区的 code 在对方系统里查不到。原因行政区划调整撤县设区、合并后本地脚本还是旧数据。解决这类静态数据要定期更新别指望一次导入用三年。做法是保留一份更新记录新脚本导入前先备份旧表用code做比对找出新增和失效的记录。如果业务对时效要求高考虑把 code 映射做成配置而不是硬编码在代码里。5.4 递归查询把数据库拖垮现象用递归 CTE 查层级时查询越来越慢甚至超时。原因递归没有终止条件写对或者数据里存在环某条记录的 parent_id 指向了自己的后代。解决递归查询务必加WHERE限制层级深度比如WHERE level 4导入后跑一次环检测确认没有parent_id指向自身或形成闭环的脏数据。静态行政区划一般不会有环但脚本被改过就说不准了。6. 进阶用法把 t_area 接进业务系统的几个实战技巧数据导进来只是第一步真正省事的是把它用顺。我一般会做三件事。第一件是加一层缓存省市区数据几乎不变没必要每次联动都查库用 Redis 把parent_id - 子节点列表缓存起来key 设计成area:children:{parentId}更新数据时整体刷新。第二件是导出成前端能直接吃的 JSON减少一次接口往返# 把 t_area 导出成嵌套 JSON供前端本地联动 import json import pymysql conn pymysql.connect(hostlocalhost, userroot, password***, databasearea_db, charsetutf8mb4) cur conn.cursor(pymysql.cursors.DictCursor) cur.execute(SELECT id, parent_id, name, code, level FROM t_area ORDER BY id) rows cur.fetchall() # 先按 parent_id 分组再递归组装 children {} for r in rows: children.setdefault(r[parent_id], []).append(r) def build(pid): return [{id: n[id], name: n[name], code: n[code], children: build(n[id])} for n in children.get(pid, [])] with open(area.json, w, encodingutf-8) as f: json.dump(build(0), f, ensure_asciiFalse) cur.close() conn.close()逻辑说明children字典按parent_id把记录分组build递归组装成树。参数上charsetutf8mb4必须写否则中文乱码ensure_asciiFalse保证 JSON 里中文正常显示。这个脚本跑一次生成静态文件前端直接加载联动零延迟。注意build(0)的起点要和你的顶级parent_id约定一致用 NULL 的话改成build(None)。第三件是给地址表做外键约束。业务表里存province_id、city_id、district_id查询时 JOINt_area拿名称。但别加数据库层面的外键行政区划更新时外键会挡住你的批量操作用应用层校验就够了。还有个细节如果业务允许用户填海外地址t_area里没有对应记录字段要允许为空别设NOT NULL。最后说个验证方法。导入完成后随机抽几个知名城市用 code 反查名称再顺着parent_id往上核对省份跑通就说明层级和编码都对。从那以后我每次拿到这类静态数据脚本都强制先跑一遍「抽三条三级链路核对」再往业务里接省得后面返工。希望帮到你。本文还有配套的精品资源点击获取