简介本资源是一份全国省、市、区三级行政区划的标准化地理坐标数据集专为GIS应用开发、LBS位置服务、地图可视化及MySQL空间数据建模等场景设计适用于中初级后端开发者、数据分析工程师与地理信息相关学习者。数据已结构化为可直接导入MySQL的SQL脚本涵盖全部34个省级行政区、333个地级市、2843个区县级单位的名称、行政编码及标准WGS84经纬度精确到小数点后6位支持快速构建地址解析、区域检索、热力图渲染等核心功能。压缩包仅含1个127KB的SQL文件无冗余脚本或说明文档开箱即用适配MySQL 5.7及以上版本导入后可立即进行空间查询与关联分析。目前已有2982人学习下载数据来源清晰、字段完整、格式规范是开展地理信息类项目开发与教学实践的高复用性基础数据支撑。1. 这不是一张静态表格它是一套可嵌入、可查询、可联动的地理坐标基础设施你正在开发一个需要按「省→市→区」三级下拉联动的地址选择器后端接口每次返回的却是全量 JSON前端卡顿、内存暴涨或者你在做区域热力图但手头的行政区划数据只有名称没有坐标硬凑百度地图 API 又被配额和跨域拦在门外又或者你刚接了个政企类 BI 看板需求客户明确要求“所有统计必须落到区县级单位”而你翻遍 GitHub 找到的 CSV 都缺经度、纬度、行政编码甚至“朝阳区”和“朝阳市”混在一起——别急这个 MySQL 数据包就是为这类真实翻车现场准备的。它不是一份导出就完事的快照而是一套结构清晰、字段完备、关系严谨、开箱即用的地理元数据底座含全国 34 个省级单位、333 个地级市、2843 个区县级行政区含市辖区、县级市、县、自治县、旗、自治旗、特区、林区每条记录带标准中文名、拼音缩写、行政编码GB/T 2260、中心经纬度WGS84、所属上级 ID、是否为直辖市/省会/计划单列市等业务标识。适合做地址补全、区域聚合、GIS 前置计算、BI 维度建模尤其适合那些没时间自己爬、不敢信第三方、又不想买商业地理服务的中小项目团队。2. 数据结构与建表逻辑为什么用三张表而不是一张宽表这个数据包不是把所有字段塞进一个areas表里完事。它采用符合第三范式的分层设计provinces省、cities市、districts区县三张主表 一张area_codes编码映射辅助表。这种设计不是为了炫技而是解决三个高频痛点一是避免冗余存储比如“广东省”的拼音、简称、编码在每个地级市记录里重复存 21 次二是支持灵活查询路径查“深圳市下所有区”直接JOIN cities ON districts.city_id cities.id不用字符串匹配三是便于后续扩展比如未来要加“乡镇级”数据只需新增towns表并关联district_id不动现有结构。2.1 核心表字段详解与设计意图先看provinces表这是整个层级的根CREATE TABLE provinces ( id int(11) NOT NULL AUTO_INCREMENT COMMENT 主键ID, code char(6) NOT NULL COMMENT GB/T 2260 省级编码如110000, name varchar(50) NOT NULL COMMENT 中文名称如北京市, pinyin varchar(100) DEFAULT NULL COMMENT 全拼如beijing shi, abbr varchar(20) DEFAULT NULL COMMENT 常用缩写如BJ, is_province_capital tinyint(1) DEFAULT 0 COMMENT 是否为本省省会对直辖市恒为1, is_municipality tinyint(1) DEFAULT 0 COMMENT 是否为直辖市1是, lng decimal(10,7) DEFAULT NULL COMMENT 中心经度WGS84, lat decimal(9,7) DEFAULT NULL COMMENT 中心纬度WGS84, created_at datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_code (code), KEY idx_name (name) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT省级行政区;提示code字段用char(6)而非varchar是因为 GB/T 2260 编码严格定长 6 位如110000、310000固定长度能提升索引效率且避免trim()操作。lng/lat使用decimal(10,7)是经过实测的平衡点7 位小数可精确到约 0.011 米赤道上远超区县级中心点精度需求同时比double节省存储、避免浮点误差。再看cities表关键在province_id外键和level字段CREATE TABLE cities ( id int(11) NOT NULL AUTO_INCREMENT, code char(6) NOT NULL COMMENT GB/T 2260 地级市编码如440300, name varchar(50) NOT NULL, pinyin varchar(100) DEFAULT NULL, abbr varchar(20) DEFAULT NULL, province_id int(11) NOT NULL COMMENT 关联 provinces.id, level tinyint(2) NOT NULL DEFAULT 1 COMMENT 行政级别1地级市2副省级市3计划单列市, lng decimal(10,7) DEFAULT NULL, lat decimal(9,7) DEFAULT NULL, is_capital tinyint(1) DEFAULT 0 COMMENT 是否为所在省省会, created_at datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_code (code), KEY idx_province_id (province_id), KEY idx_name (name), CONSTRAINT fk_cities_province_id FOREIGN KEY (province_id) REFERENCES provinces (id) ON DELETE CASCADE ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT地级行政区含副省级、计划单列;注意level字段它不只记录“是不是副省级”更关键的是为前端渲染提供依据——比如在下拉菜单中计划单列市如深圳、厦门常需加粗或标星这个字段就是最干净的判断依据无需再查name IN (深圳,厦门,宁波...)。最后是districts表它承载了最细粒度的业务需求CREATE TABLE districts ( id int(11) NOT NULL AUTO_INCREMENT, code char(6) NOT NULL COMMENT GB/T 2260 区县级编码如440303, name varchar(50) NOT NULL, pinyin varchar(100) DEFAULT NULL, abbr varchar(20) DEFAULT NULL, city_id int(11) NOT NULL COMMENT 关联 cities.id, type tinyint(2) NOT NULL DEFAULT 1 COMMENT 类型1市辖区2县级市3县4自治县5旗6自治旗7特区8林区, lng decimal(10,7) DEFAULT NULL, lat decimal(9,7) DEFAULT NULL, is_urban tinyint(1) DEFAULT 1 COMMENT 是否为城区影响热力图权重, created_at datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_code (code), KEY idx_city_id (city_id), KEY idx_name (name), CONSTRAINT fk_districts_city_id FOREIGN KEY (city_id) REFERENCES cities (id) ON DELETE CASCADE ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT区县级行政区;type字段是血泪经验很多项目后期要做“城区 vs 县域”差异化分析比如外卖订单密度、宽带覆盖率如果只靠name含“区”字来判断会漏掉“昆山市”“义乌市”这类强城区属性的县级市也会误判“鄂尔多斯市东胜区”它确实是区但name里没“区”字。type字段让这种判断变成WHERE type IN (1,2)的简单查询。2.2 辅助表area_codes为什么需要它你可能会问GB/T 2260 编码已经能唯一标识行政区为什么还要一张area_codes答案是——现实业务中用户输入的编码五花八门有带空格的11 0000有带横线的11-0000有旧版 4 位码1100甚至还有港澳台特殊编码990000。area_codes表专门处理这些变体CREATE TABLE area_codes ( id int(11) NOT NULL AUTO_INCREMENT, standard_code char(6) NOT NULL COMMENT 标准6位码如110000, variant varchar(20) NOT NULL COMMENT 变体形式如11 0000或1100, area_type tinyint(1) NOT NULL DEFAULT 1 COMMENT 1省2市3区县, created_at datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), KEY idx_standard_code (standard_code), KEY idx_variant (variant) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT行政区划编码变体映射;实际使用时你的清洗脚本可以这样写-- 将用户输入的任意编码标准化 SELECT standard_code FROM area_codes WHERE variant REPLACE(REPLACE(11-0000, -, ), , ); -- 返回 110000这比在应用层用正则反复替换可靠得多也避免了因编码格式不统一导致的关联失败。2.3 关系完整性与性能保障三张主表之间通过ON DELETE CASCADE级联删除确保删除一个省时其下属所有市、区自动清理不会留下孤儿记录。但要注意生产环境慎用CASCADE。我们建议在初始化数据时启用它快速构建干净数据上线后改为手动维护即删除前先查子表是否存在记录。另外所有code字段都建了UNIQUE KEY uk_code这是强制数据质量的底线——绝不能出现两个“北京市”或两个110000。索引策略上除主键外每张表都建了KEY idx_name (name)。这不是为了加速WHERE name ?这种查询极少而是为ORDER BY name和LIKE 北京%提供支撑。实测表明在districts表2800 条上ORDER BY name从 120ms 降到 8ms对前端分页加载很关键。3. 初始化与导入从 SQL 文件到可查询数据库的完整链路拿到.sql文件后别急着mysql -u root -p data.sql。这个包包含 4 个核心文件provinces.sql、cities.sql、districts.sql、area_codes.sql它们有严格的执行顺序。跳过provinces直接导入cities会因外键约束失败——MySQL 默认开启FOREIGN_KEY_CHECKS。3.1 安全导入四步法含错误拦截第一步创建数据库并指定字符集关键mysql -u root -p -e CREATE DATABASE IF NOT EXISTS geo_db CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;注意必须用utf8mb4否则“乌鲁木齐全”等带生僻字的区名会乱码或截断。utf8在 MySQL 中实际是utf8mb3不支持 4 字节 Unicode如 emoji、部分少数民族文字。第二步关闭外键检查按顺序导入provinces→cities→districts→area_codesmysql -u root -p geo_db -e SET FOREIGN_KEY_CHECKS 0; mysql -u root -p geo_db provinces.sql mysql -u root -p geo_db cities.sql mysql -u root -p geo_db districts.sql mysql -u root -p geo_db area_codes.sql mysql -u root -p geo_db -e SET FOREIGN_KEY_CHECKS 1;第三步验证数据完整性必做-- 检查各省是否有对应市排除直辖市被漏掉 SELECT p.name, COUNT(c.id) as city_count FROM provinces p LEFT JOIN cities c ON p.id c.province_id GROUP BY p.id, p.name HAVING city_count 0; -- 检查所有区县是否归属有效市级揪出 orphan records SELECT d.name, d.code, d.city_id FROM districts d LEFT JOIN cities c ON d.city_id c.id WHERE c.id IS NULL;如果返回结果为空说明数据关系健康。一旦发现city_count 0大概率是provinces.sql里漏了某个省如台湾省编码710000是否被过滤需回溯源文件。第四步重建索引导入后首次执行-- 对大表 districts 执行提升后续 JOIN 效率 ALTER TABLE districts ENGINEInnoDB;这会触发 MySQL 重建聚簇索引消除导入过程中产生的碎片。实测districts表2843 行执行后JOIN cities查询速度提升约 35%。3.2 常见问题排查导入失败的 4 个高频雷区现象执行mysql -u root -p geo_db provinces.sql报错ERROR 1062 (23000): Duplicate entry 110000 for key uk_code原因数据库geo_db已存在同名表且provinces表里已有数据而provinces.sql文件中的INSERT语句未加IGNORE或ON DUPLICATE KEY UPDATE。解决清空库重来或修改 SQL 文件在每条INSERT前加INSERT IGNORE INTO provinces ...。更推荐前者确保数据纯净。现象导入后SELECT * FROM provinces LIMIT 1;返回中文乱码如??或?原因客户端连接字符集未设为utf8mb4。即使数据库和表是utf8mb4客户端用latin1连接也会显示乱码。解决在连接命令中显式指定mysql -u root -p --default-character-setutf8mb4 geo_db并在 MySQL 配置文件my.cnf中全局设置[client] default-character-set utf8mb4 [mysqld] character-set-server utf8mb4 collation-server utf8mb4_unicode_ci现象cities.sql导入时报Cannot add or update a child row: a foreign key constraint fails原因cities.sql中某条记录的province_id值在provinces表中不存在。常见于手动编辑过 SQL 文件或provinces.sql未成功执行。解决先运行SELECT id, code, name FROM provinces;确认省表已就绪再检查cities.sql中报错行的province_id值是否在该结果集中。若缺失需补全provinces.sql或修正cities.sql。现象导入完成但SELECT COUNT(*) FROM districts;返回0原因districts.sql文件末尾可能有多余的-- 注释或空行导致 MySQL 解析中断。某些编辑器如 Windows 记事本保存时添加了 BOM 头也会破坏 SQL 解析。解决用vim districts.sql查看首行是否为-- MySQL dump...用file -i districts.sql检查编码确保是utf-8无 BOM用dos2unix districts.sql清理 Windows 换行符。4. 核心查询模式5 类高频业务场景的 SQL 写法与性能要点数据导入只是起点真正价值在于怎么用。下面 5 个查询覆盖了 80% 的地理相关需求每条都附带执行计划分析和优化建议。4.1 场景一根据用户输入的模糊名称返回匹配的省市区三级结构地址搜索这是前端地址组件的刚需。不能只查districts.name LIKE %朝阳%因为“朝阳区”和“朝阳市”都会命中需按层级优先级排序。-- 推荐写法UNION ALL 分层查询用 ORDER BY LIMIT 控制返回量 (SELECT province AS level, id, name, code, lng, lat FROM provinces WHERE name LIKE %朝阳%) UNION ALL (SELECT city AS level, id, name, code, lng, lat FROM cities WHERE name LIKE %朝阳%) UNION ALL (SELECT district AS level, id, name, code, lng, lat FROM districts WHERE name LIKE %朝阳%) ORDER BY CASE level WHEN province THEN 1 WHEN city THEN 2 ELSE 3 END, LENGTH(name) LIMIT 10;逻辑说明UNION ALL比UNION快不查重CASE排序确保“省”排最前“区县”排最后LENGTH(name)让“朝阳区”4字排在“朝阳市双塔区”7字前面更符合用户直觉。实测在districts表上name LIKE %朝阳%全表扫描耗时 15ms加idx_name索引后降至 3ms。4.2 场景二获取某市下所有区县并标注是否为城区用于热力图分级SELECT d.id, d.name, d.lng, d.lat, d.is_urban, CASE WHEN d.type IN (1,2) THEN high_density -- 市辖区、县级市 WHEN d.type IN (3,4) THEN medium_density -- 县、自治县 ELSE low_density -- 旗、特区等 END AS density_level FROM districts d JOIN cities c ON d.city_id c.id WHERE c.code 440300; -- 深圳市参数说明c.code 440300比c.name 深圳市更可靠避免因“市”字省略如“深圳”或繁体字导致匹配失败。density_level字段直接输出给前端省去 JS 判断。4.3 场景三计算两地点间直线距离Haversine 公式简化版虽然高德/百度提供 API但简单距离判断如“用户是否在本市范围内”用 SQL 更快SELECT d.name, ROUND( 6371 * ACOS( COS(RADIANS(22.5431)) * COS(RADIANS(d.lat)) * COS(RADIANS(d.lng) - RADIANS(114.0579)) SIN(RADIANS(22.5431)) * SIN(RADIANS(d.lat)) ), 2 ) AS distance_km FROM districts d WHERE d.city_id 123 -- 某市ID HAVING distance_km 50 ORDER BY distance_km;逻辑说明22.5431/114.0579是用户当前坐标纬度/经度6371是地球平均半径km。HAVING而非WHERE是因为distance_km是计算字段。此查询在districts表上执行约 8ms比调用一次 HTTP API通常 100ms快一个数量级。4.4 场景四生成省-市-区三级树形结构JSON 格式供前端渲染MySQL 8.0 支持JSON_OBJECT和JSON_ARRAYAGG可一步生成SELECT JSON_OBJECT( province, p.name, code, p.code, cities, JSON_ARRAYAGG( JSON_OBJECT( city, c.name, code, c.code, districts, ( SELECT JSON_ARRAYAGG( JSON_OBJECT(name, d.name, code, d.code) ) FROM districts d WHERE d.city_id c.id ) ) ) ) AS tree_data FROM provinces p JOIN cities c ON p.id c.province_id GROUP BY p.id, p.name, p.code LIMIT 5;注意此查询对cities表做了GROUP BY若某省无市如直辖市需改用LEFT JOIN并处理NULL。生产环境建议分步查询先取省列表再对每个省SELECT * FROM cities WHERE province_id ?最后对每个市取区县——减少单次查询复杂度更易缓存。4.5 场景五统计各省份的区县数量及平均经纬度BI 维度建模SELECT p.name AS province_name, COUNT(d.id) AS district_count, ROUND(AVG(d.lng), 5) AS avg_lng, ROUND(AVG(d.lat), 5) AS avg_lat, MIN(d.lng) AS min_lng, MAX(d.lng) AS max_lng, MIN(d.lat) AS min_lat, MAX(d.lat) AS max_lat FROM provinces p JOIN cities c ON p.id c.province_id JOIN districts d ON c.id d.city_id GROUP BY p.id, p.name ORDER BY district_count DESC;性能要点JOIN顺序很重要。先provinces → cities333 行再cities → districts2843 行比provinces → districts需笛卡尔积高效得多。ROUND(...,5)防止小数位过多影响 JSON 序列化。5. 二次开发改造指南从“能用”到“好用”的 3 个关键升级这个数据包交付的是一个坚实基座但真实项目永远有定制需求。我经历过至少 5 个项目基于它二次开发总结出三个最值得投入的改造方向增加乡镇级数据、接入实时坐标校准、构建空间索引。下面给出可直接落地的代码和验证方法。5.1 升级一扩展乡镇级towns表支持四级联动很多政务系统要求“省-市-区-镇”四级下拉。直接在districts表加parent_id不够优雅应新建towns表CREATE TABLE towns ( id int(11) NOT NULL AUTO_INCREMENT, code char(9) NOT NULL COMMENT GB/T 2260 乡镇级编码如440303001, name varchar(50) NOT NULL, pinyin varchar(100) DEFAULT NULL, district_id int(11) NOT NULL COMMENT 关联 districts.id, lng decimal(10,7) DEFAULT NULL, lat decimal(9,7) DEFAULT NULL, created_at datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_code (code), KEY idx_district_id (district_id), CONSTRAINT fk_towns_district_id FOREIGN KEY (district_id) REFERENCES districts (id) ON DELETE CASCADE ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT乡镇级行政区;关键改造点code从 6 位升为 9 位GB/T 2260 乡镇码规则district_id外键指向districts.id。导入时先确保districts表已存在再执行towns.sql。查询四级联动时只需多一层JOINSELECT p.name AS province, c.name AS city, d.name AS district, t.name AS town FROM towns t JOIN districts d ON t.district_id d.id JOIN cities c ON d.city_id c.id JOIN provinces p ON c.province_id p.id WHERE t.code 440303001;5.2 升级二用 MySQL 5.7 的ST_Point类型替代lng/lat字段启用空间索引原设计用decimal存经纬度虽简单但无法利用空间函数如ST_Distance_Sphere。升级为POINT类型后查询“某点 5km 内所有区县”可提速 5 倍-- 修改 districts 表添加 point 字段并建立空间索引 ALTER TABLE districts ADD COLUMN location POINT SRID 4326, ADD SPATIAL INDEX idx_location (location); -- 批量更新将 lng/lat 转为 POINT UPDATE districts SET location ST_POINTFROMTEXT(CONCAT(POINT(, lng, , lat, )), 4326); -- 查询深圳市民中心114.0579,22.54315km 内的区县 SELECT name, ROUND(ST_DISTANCE_SPHERE(location, ST_POINTFROMTEXT(POINT(114.0579 22.5431), 4326))/1000, 2) AS distance_km FROM districts WHERE ST_CONTAINS(ST_BUFFER(ST_POINTFROMTEXT(POINT(114.0579 22.5431), 4326), 5000), location);验证方法执行EXPLAIN查看key是否为idx_location。若显示type: range说明空间索引生效。注意SRID 4326是 WGS84 坐标系标准必须指定否则ST_DISTANCE_SPHERE会报错。5.3 升级三构建轻量级坐标校准机制应对 POI 偏移原始经纬度是行政区“中心点”但实际业务中用户上报的 GPS 坐标常有偏移如 iOS 设备在中国大陆的 GCJ-02 偏移。与其集成庞大 SDK不如在数据库层做简单校准-- 新增校准表存储常见 POI 的偏移量单位米 CREATE TABLE coordinate_offset ( id int(11) NOT NULL AUTO_INCREMENT, area_code char(6) NOT NULL COMMENT 区县级编码, dx int(11) DEFAULT 0 COMMENT 经度偏移米, dy int(11) DEFAULT 0 COMMENT 纬度偏移米, updated_at datetime DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_area_code (area_code) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; -- 插入深圳南山区校准值示例 INSERT INTO coordinate_offset (area_code, dx, dy) VALUES (440305, 120, -85);然后在查询时动态修正SELECT d.name, ROUND(d.lng (o.dx / (111320 * COS(RADIANS(d.lat)))), 7) AS corrected_lng, ROUND(d.lat (o.dy / 110540), 7) AS corrected_lat FROM districts d LEFT JOIN coordinate_offset o ON d.code o.area_code WHERE d.code 440305;逻辑说明111320是赤道上 1 度经度≈111.32km110540是 1 度纬度≈110.54kmCOS(RADIANS(d.lat))修正纬度对经度距离的影响。这个公式在中低纬度误差5 米足够业务使用。从那以后我每次部署新区域数据都强制走一遍coordinate_offset表的校准值录入流程——哪怕先填 0也留出扩展口。希望帮到你。本文还有配套的精品资源点击获取