全球旅游城市SQL数据包：解压导入MySQL与数据校验全攻略

简介一份覆盖全球旅游城市的 MySQL 数据文件以可直接运行的 SQL 语句形式呈现内含 6000 条记录聚焦餐饮旅游行业。数据维度涵盖城市名称、地理位置、人口数量、著名景点与餐饮业信息可用于旅游趋势分析、餐饮分布统计和相关业务决策。压缩包采用 RAR 格式仅含 1 个 travel_area.sql 文件包体仅 133KB下载后即可直接导入 MySQL无需额外配置。目前已有 317 人学习下载。借助这份数据分析人员可快速查询热门目的地、比较各城市餐饮业发达程度开发者可将其接入预订系统或推荐平台用于实时信息展示学生亦可作为毕业设计或课程项目的数据支撑。对于学习 MySQL 导入导出、数据库设计、数据清洗及查询优化的初学者这份现成的真实业务数据也是良好的练习素材且 SQL 语句已预先处理建表与插入逻辑执行一次即可完成数据准备帮助理解从数据整理到分析应用的全流程。1. 一份能直接跑的全球旅游城市SQL数据包先搞清它解决什么问题做旅游类小程序或者数据可视化大屏的时候最烦的不是写SQL而是没有一份能直接用的城市基础数据。自己爬回来的东西要么名称不统一要么缺经纬度清洗一天下来人都麻了。这个标题给的是现成的解决方案一个RAR压缩包里面装着建表语句和INSERT数据共6000多条全球旅游城市记录解压后导入MySQL就能直接SELECT。它解决的问题不是帮你造数据而是把数据整理成可复用的SQL语句——适合做原型验证、课程设计、内部工具和数据分析的人。如果业务需要的是实时更新的城市POI数据那它不够用但作为离线基准数据性价比很高。2. 解压后不是终点先看文件清单、建表语句和字段预期标题把RAR和MySQL放在一起真正的第一步永远是解压并检查文件清单。很多人拿到压缩包直接双击拖出来就导入结果不是表名冲突就是字段对不上来回折腾的时间比导入本身还长。这一章把导入前半小时该做的事拆开讲。2.1 解压RAR是第一步先看文件清单别急着导RAR不是SQL裸文件先解压到独立目录再按文件大小和清单判断导入策略。# 用7-Zip解压到指定目录-o后面是输出目录注意不带空格 7z x 全球旅游城市数据整理.rar -o./tour_city_sql # 如果你在Linux服务器上通常用unrar unrar x 全球旅游城市数据整理.rar ./tour_city_sql/ # 解压后按文件大小排序看看里面到底有哪几个文件 ls -lhS ./tour_city_sql/参数说明7z x的x是带路径解压区别于e不解压目录结构直接丢到当前目录-o指定输出目录注意参数后面不要跟空格unrar x同样保留压缩包内的目录层级。之所以强调独立目录是避免SQL文件散落到当前目录和别的文件混在一起后面清理都麻烦。解压出来通常是一个或多个.sql文件可能还带一个 README 或说明文档。先ls看文件清单比直接双击导入靠谱得多。重点看两件事SQL文件有几个最大的文件是哪个。如果只有一个SQL文件那建表和INSERT大概率在同一个文件里如果拆成多个那通常有导入顺序先执行结构文件再执行数据文件。2.2 静态检查SQL脚本导入之前先看建表语句和INSERT格式在导入前花5分钟对SQL脚本做一次静态检查能省掉后续排查半天的时间。# 查看脚本里的建表语句假设解压出tour_city.sql grep -n CREATE TABLE tour_city.sql | head -20 # 查看INSERT语句是单行多VALUES还是逐条INSERT grep -n INSERT INTO tour_city.sql | head -5 # 统计总行数和文件大小对数据量有个预期 wc -l tour_city.sql du -h tour_city.sqlgrep输出的价值在于建表语句决定了表名、字段数、字段类型和字符集后面所有查询都基于它INSERT INTO的写法决定了导入效率。如果是INSERT INTO ... VALUES (...),(...),(...)这种一条语句插几千行的写法导入速度会很快但单条语句过大可能触发max_allowed_packet限制如果是一行一条INSERT那6000多条数据要执行6000多次导入慢但对内存压力小。wc -l看到的总行数和du看到的文件大小可以估算导入耗时。6000多行的逐行INSERTSQL文件大约在几万行左右算上建表、注释和换行MySQL导入通常是秒级到分钟级。如果发现文件有几十万行说明INSERT是逐行的或者夹杂了大量索引定义导入时间稍微拉长而已不用慌。2.3 建表语句里的三个隐藏信号DROP TABLE、字符集、存储引擎看建表语句的时候重点盯三个位置。# 查看完整的建表语句用sed截取指定行 sed -n 10,30p tour_city.sql # 检查脚本里是否有DROP TABLE操作 grep -n DROP TABLE tour_city.sql第一个信号是DROP TABLE。很多数据包为了做到可重复导入会在建表前执行DROP TABLE IF EXISTS。如果你之前已经在同名表里积累了业务数据导入就会把它们清空。这是我每次导入前必查的一项查完再决定要不要手动注释掉。第二个信号是字符集。建表语句里的DEFAULT CHARSET如果是utf8mb4那基本不用动如果是latin1或utf8后面导入中文内容时就要小心乱码。第三个信号是存储引擎。ENGINEInnoDB是默认如果脚本里写的是MyISAM也没问题但如果你的高版本MySQL对事务或外键有要求建议导入后统一转成InnoDB免得后续业务踩到引擎差异的坑。2.4 字段设计的常见预期这种包通常怎么组织6000条数据从标题只能确认全球旅游城市数据和6000具体字段标题没写。以这类数据包的常见做法来看一般会包含下面几类信息字段类型常见取值示例用途城市名Paris、Tokyo、Bangkok核心字段通常有唯一性约束国家或地区France、Japan按国家筛选和分组大洲/区域Europe、Asia地理区域划分经纬度经度、纬度浮点数地图打点、距离计算人口/时区整数或VARCHAR排序、参考展示这张表的用意是帮你建立预期不是背字段名。导入之后先执行DESC查看真实结构所有示例SQL里的city_name、country字段都要按实际表名替换。关于6000的密度判断全球叫得上名字的旅游城市大致就是这个量级说明它整理的是城市这一级不是景区或POI级。用来做城市列表、旅游选品、数据可视化是合理的如果你需要按景点、酒店、航班去查那这个数据包覆盖不到别指望它。做预期管理的意义就在这里——先搞清楚边界后面才不会失望。3. 把SQL导入MySQL环境准备、两条导入路径和一个日志习惯这一章从建库开始到两条可选的导入命令最后落到日志留存。环境默认你已经装好了MySQL 8.0或5.7安装和配置教程网上一搜一大把这里直接从导入开始讲。整个过程我建议都在命令行完成图形工具在中小数据量下没问题但遇到字符集或大语句时命令行反馈更透明。3.1 先建独立库用utf8mb4做兜底拿到SQL文件第一件事不是双击打开而是先在MySQL里建好独立数据库。数据包自带建表语句但不一定自带建库语句用独立库的好处是导入失败不影响其他业务表、清掉重来方便、做完校验再考虑并入业务库。-- 创建独立数据库专门用来放这份旅游城市数据 CREATE DATABASE IF NOT EXISTS tour_db DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; USE tour_db;utf8mb4是MySQL里真正意义上的全量UTF-8能存下4字节的emoji和生僻字。城市名里如果包含特殊拉丁字符比如São Paulo的ã、Reykjavík的í用老的utf8也能存但如果数据作者混入了一些特殊符号utf8mb4更稳。排序规则我一般选utf8mb4_general_ci比utf8mb4_unicode_ci快一点点城市名字段也不涉及复杂排序够用。如果数据包里的SQL脚本自带SET NAMES或USE语句导入时它会自己切库你提前建的库可能白建——没关系建库本身不花时间真被脚本内的USE覆盖了再去那个库看数据即可。这个兜底动作的价值在于最坏情况也只会污染独立库不会把手头的业务数据搞乱。3.2 用source命令导入交互式导入的适用场景source是mysql客户端内置命令在交互式会话里执行路径直接指向本地文件。# 先登录MySQL客户端 mysql -u root -p # 进入客户端后依次执行 SET NAMES utf8mb4; USE tour_db; SOURCE /home/user/tour_city.sql;三条命令是顺序执行的关系SET NAMES utf8mb4把客户端这次会话的字符集设为utf8mb4避免SQL文件里带中文时被客户端转码转乱USE tour_db切到目标库SOURCE是mysql客户端的命令后面跟文件绝对路径相当于把文件内容一条条喂给客户端执行。source适合什么场景文件不大几十MB以内你想看着每条语句的执行反馈。执行完最后会显示Query OK, 6000 rows affected之类的结果如果某条语句报错错误会直接打在屏幕上。缺点也在这SQL文件里如果有几十个错误屏幕会快速滚走所以你要配合日志方式一起用。3.3 用mysql重定向导入非交互式导入的适用场景如果你把SQL文件放到服务器上或者文件到了几百MBsource的交互式体验反而碍事直接用shell重定向更稳。# 用mysql命令重定向导入数据不会经过客户端交互界面 mysql -u root -p --default-character-setutf8mb4 tour_db tour_city.sql # 如果导出SQL时用了local-infile导入时也要对应放开 mysql -u root -p --default-character-setutf8mb4 \ --local-infile1 tour_db tour_city.sql参数解释--default-character-setutf8mb4和刚才的SET NAMES作用一致只不过是在连接阶段生效是shell重定向把SQL文件内容作为标准输入喂给mysql进程--local-infile1只在脚本里用了LOAD DATA LOCAL INFILE时才需要如果脚本是纯INSERT可以不加。重定向导入的好处是不用守着交互界面、退出终端也不影响、适合写进部署脚本。坏处是看不到逐条执行进度如果出错也不知道停在哪。所以重定向导入的时候务必加日志记录。3.4 导入日志是最后的后悔药我自己的习惯是无论哪种方式导入都把输出落盘。这样即便过了一天才发现数据有问题也能通过日志定位到当时报错的位置不用重新猜。# 带日志导入-vvv输出详细执行信息 mysql -u root -p --default-character-setutf8mb4 \ --show-warnings -vvv tour_db tour_city.sql \ import.log 21 # 导入完成后检查错误 grep -i error import.log | head -20 # 看最后几行确认执行结果 tail -n 20 import.log-vvv是verbosity级别控制台会打印比较详细的执行信息配合21把标准错误也重定向到同一个日志文件。--show-warnings会显示每条语句的Warning比如字段被截断无效编码这类不影响导入但值得留意的信息。导入完成后不要只看tail先grep -i error。有ERROR就说明有语句没执行成功要进行下一步校验。没有ERROR也不等于数据完美还要做下一章的校验。日志文件建议保留到确认数据可用后再删线上环境尤其如此。4. 导入成功不等于数据可用做全量、空值和抽样三重校验导入完看到Query OK就算结束了吗远远没有。我见过太多数据包导入成功但数据质量一塌糊涂的情况缺字段、乱码、重复率高。这一章讲怎么用SQL把这6000条数据从头到尾盘一遍。4.1 用COUNT(*)验证总行数对不上6000才需要慌导入完成不等于导入正确第一件事永远是数行数。-- 查询总行数和标题里的6000对一对 -- 注意表名和字段名按你导入后的真实结构替换 SELECT COUNT(*) AS total_count FROM tour_city;如果total_count在6000以上数量级对上了接下来做抽样。如果差很多比如只有3000原因大概率是两种SQL脚本执行到一半报错后面的INSERT没执行成功这种情况要回到导入日志里定位或者解压出来的SQL文件本身不完整直接看文件大小是否合理。如果比6000多很多比如60000那可能是6000的单位不是条而是包里还有其他表的数据或者字段里混入了行政区划级别的明细。这时候要结合文件里的表名数量来判断别急着高兴数据多。4.2 空值率和重复值检查一条SQL揪出数据质量问题数据包整理得好不好看空值率和重复率最直接。-- 城市名字段的空值统计SUM(字段 IS NULL)是统计空值的常用写法 SELECT COUNT(*) AS total, SUM(city_name IS NULL) AS name_null, SUM(country IS NULL) AS country_null FROM tour_city; -- 城市名重复情况重复说明数据整理时可能混入了别名 SELECT city_name, COUNT(*) AS cnt FROM tour_city GROUP BY city_name HAVING cnt 1 ORDER BY cnt DESC LIMIT 10;SUM(字段 IS NULL)是MySQL里统计空值数量的常用写法避免用WHERE city_name IS NULL再查一次。如果空值率超过5%这个包的整理质量就一般后面使用时要对关键字段做兜底。比如城市名为空的记录在地图打点时会直接显示不出来那这条记录在这个场景下基本不可用。重复检查也很抓细节同一个城市可能以不同拼写入库比如Prague和PrahaGROUP BY只能查出完全相同的重复。真要查别名级重复得靠人工或专业清洗工具。这个边界要知道但不需要在数据包阶段就处理先确认没有完全重复即可。4.3 用已知城市做交叉验证抽查世界级地标和最冷门目的地全部6000多条数据人肉检查不现实我的做法是挑两类城市做交叉验证一类是世界级地标城市出现频率极高一类是冷门旅游城市如果冷门的也有说明数据来源比较全。-- 用IN查询一批大家耳熟能详的世界级旅游城市 SELECT city_name, country FROM tour_city WHERE city_name IN (Paris, Tokyo, Bangkok, Rome, Barcelona); -- 用LIKE做模糊匹配验证名称变体识别能力 SELECT city_name, country FROM tour_city WHERE city_name LIKE San%;第一类查不出来说明数据源对世界级城市都有遗漏那这个包的质量就存疑。第二类查询能看出城市名字段的命名风格LIKE San%能同时命中San Francisco、San Diego、San Sebastian如果你希望做城市搜索联想这些变体是绕不过去的。这里有一个常见的预期差如果这个包自带的是拼音或英文名而你希望按中文搜索那后续还要做中文名映射别指望一次导入全部满足需求。交叉验证的目的就是尽早暴露这种预期差趁数据还没进业务库就做决策。4.4 数据新鲜度怎么判断标题没写时间时的处理标题只写了共6000数据没有写数据生成时间。旅游城市的基础属性名称、经纬度、所属国家或地区变化很慢几年内不会有太大变化所以只要城市存在这批数据的基础价值还在。但如果你要把数据用在是否免签航线是否直飞这类动态属性上那这个包大概率不适用——城市还是那座城市政策早就换了。我的经验是静态的城市基础数据可以放心用动态的旅游政策数据不要依赖这种一次性数据包。真要核对时效拿几个近期热门的新兴旅游目的地去查如果缺失说明采集时点比较早后续要自己补充增量数据。数据新鲜度不是能不能用的问题而是怎么用好它的问题。5. 避坑清单导入这6000条旅游城市数据时的5个典型踩坑记录这一章专门写踩坑每条按现象 → 原因 → 解决展开。都是我遇到过或者身边同事遇到过的问题按频率从高到低排。第5.4条还涉及一个判断要不要花时间破解RAR密码我的建议是别。5.1 报错 ERROR 1273不同MySQL版本间的排序规则冲突现象导入SQL文件时建表语句直接报ERROR 1273 (HY000): Unknown collation: utf8mb4_0900_ai_ci后续所有语句全部停止。原因utf8mb4_0900_ai_ci是MySQL 8.0的默认排序规则而导入环境的MySQL版本是5.7或更早不识别这个排序规则。数据包作者在8.0上导出没有考虑向下兼容。解决两条路。一是把SQL文件里的utf8mb4_0900_ai_ci全部替换为utf8mb4_general_ci用sed -i s/utf8mb4_0900_ai_ci/utf8mb4_general_ci/g tour_city.sql处理后重新导入二是直接升级到MySQL 8.0。本地开发环境我推荐后者一劳永逸线上要让DBA评估兼容性用sed替换更省事。替换前注意备份原始文件万一替换出问题还能回滚。5.2 导入成功但中文全部变成问号现象导入后SELECT查出来中文城市名全是???或者显示成类似ä¸æµ·的乱码。原因SQL文件本身是UTF-8编码但导入时的客户端字符集不是utf8mb4。常见于直接用图形工具导入而没设置连接字符集或者在执行SET NAMES之前就已经把文件内容读进了会话。解决导入前统一执行SET NAMES utf8mb4命令行导入加--default-character-setutf8mb4用图形工具的话把连接属性里的character set也改成utf8mb4。已经导乱的表只能删掉重新导入没有后悔药。所以第3章才反复强调字符集先行这一步省不掉。5.3 同名表被覆盖业务数据没了现象导入后发现之前维护的城市相关表变成了这个数据包的表结构原来自己整理的数据全都不见了。原因很多可重复导入的SQL脚本会在建表前写DROP TABLE IF EXISTS保证重复执行不报错。这正是标题里可直接运行的代价——它对已有同名表是毁灭性的。解决导入前先执行grep -n DROP TABLE tour_city.sql确认有就手动注释。如果已经发生覆盖只能从备份恢复——这就是为什么每次都要建独立库再导入。如果没有备份这条数据就永远丢了本地开发环境还好线上环境就是事故。我的固定做法是任何第三方SQL脚本进库之前DROP TABLE这一行必须自言自语一遍我看过了我确认了。5.4 RAR解压报文件头损坏或提示输入密码现象双击压缩包解压时提示文件头损坏或要求输入密码文件完全出不来。原因下载来源不完整或者压缩包本身被作者加密。也可能是解压工具版本太老不支持压缩包使用的新算法。这三种情况的表现接近但处理方式完全不同。解决先看文件大小和来源页面标称是否一致重新下载一次下载时不要用断点续传有些网盘工具的断点续传会把文件写坏。如果确认文件完整但需要密码去来源页面看说明很多包密码就写在标题下方或者打包说明里。不要用Advanced RAR Password Recovery之类工具暴力破解旅游城市基础数据不是加密敏感资料为它花时间不值得直接找来源页面更靠谱。解压这种事有时候也讲点玄学换个解压工具比如用7-Zip替换WinRAR就能通过的情况我也见过。5.5 一条INSERT插几千行导入时被max_allowed_packet卡住现象导入到一半报ERROR 1153 (HY000): Got a packet bigger than max_allowed_packet bytes然后连接断开导入中断。原因数据包为了减小文件体积和提高导入速度把几千行压缩成一条INSERT INTO ... VALUES (...),(...),...单条语句超过MySQL默认的max_allowed_packet限制默认4M。解决导入前在MySQL会话里调大限制执行SET GLOBAL max_allowed_packet 64 * 1024 * 1024;然后重新登录客户端再执行导入。也可以用命令行启动参数--max-allowed-packet64M。注意SET GLOBAL只对后续新建立的连接生效当前连接里设置完接着导入是无效的一定要重新连接一次。如果还卡就考虑用第3.3节的命令行重定向方式导入它的内存管理比图形工具更可控。6. 让这6000条数据真正可用索引、备份与查询落地数据导进去只是第一步让它稳定服务业务才是目的。这一章讲三件事建索引、做备份、封装查询。这三件事做完这份旅游城市数据才算真正变成了可用的基础数据。6.1 给常用查询字段建索引别让慢SQL拖后腿这种一次性导入的静态数据建索引的收益在混合查询时尤其明显。-- 城市名是查询最频繁的字段加普通索引 ALTER TABLE tour_city ADD INDEX idx_city_name (city_name); -- 如果经常按国家或大洲筛选建议建单独索引 ALTER TABLE tour_city ADD INDEX idx_country (country);6000多条数据不建索引其实也查很快但如果这个表后面会被业务频繁JOIN或者你做了WHERE city_name ?这种等值查询索引能让查询计划从全表扫变成索引查找。要注意LIKE %Paris%这种前后模糊查询不会走索引只能全表扫这是MySQL的常规表现不是数据包的问题。真遇到高频模糊搜索再考虑用全文索引或者外部搜索组件。6.2 日常维护备份放在业务库之外静态数据包导入后最怕两件事误删、误改。我的做法是导入验完立即做一次逻辑备份。# 备份整个库--single-transaction保证备份期间读一致性 mysqldump -u root -p --single-transaction \ --default-character-setutf8mb4 tour_db tour_db_init_backup.sql这份备份可以和业务库备份分开存放也可以单独归档。以后每次向库里补充数据都先备份再操作养成习惯之后几乎没有误操作后恢复不了的焦虑。给数据包做版本管理的另一个习惯把解压出来的原始SQL文件放到一个Git仓库里后续改了字段、补了数据都有一条清晰的变更记录比在数据库里直接改还不知道改了什么强得多。6.3 把一份静态数据变成可用服务数据包的价值在于落地。后端最常见的用法是提供一个城市搜索接口查询时用参数化SQL而不是拼接字符串避免SQL注入。-- 搜索接口的查询语句城市名和国籍都是参数 SELECT city_name, country, lat, lng FROM tour_city WHERE city_name LIKE CONCAT(%, ?, %) LIMIT 20;?是PreparedStatement的参数占位符后端通过参数绑定传值这是防SQL注入的底线做法不管数据量多大都不能省。城市数据看似简单但对接了搜索、地图打点、旅游推荐之后它就是一套微型旅游业务的基础层。到今天我还保留着一个习惯任何第三方的SQL数据包导入前先跑三行命令——grep DROP TABLE看它敢不敢删表、wc -l看文件规模、head -20看编码开头。这三步用到现在救回过不少差点被覆盖的本地表。做数据整合这行稳永远比快重要。希望帮到你。本文还有配套的精品资源点击获取