全球旅游城市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.sql

grep输出的价值在于：建表语句决定了表名、字段数、字段类型和字符集，后面所有查询都基于它；INSERT INTO的写法决定了导入效率。如果是INSERT INTO ... VALUES (...),(...),(...)这种一条语句插几千行的写法，导入速度会很快，但单条语句过大可能触发max_allowed_packet限制；如果是一行一条INSERT，那6000多条数据要执行6000多次，导入慢但对内存压力小。

wc -l看到的总行数和du看到的文件大小可以估算导入耗时。6000多行的逐行INSERT，SQL文件大约在几万行左右（算上建表、注释和换行），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，后面导入中文内容时就要小心乱码。

第三个信号是存储引擎。ENGINE=InnoDB是默认，如果脚本里写的是MyISAM也没问题，但如果你的高版本MySQL对事务或外键有要求，建议导入后统一转成InnoDB，免得后续业务踩到引擎差异的坑。

2.4 字段设计的常见预期：这种包通常怎么组织6000+条数据

从标题只能确认"全球旅游城市数据"和"6000+"，具体字段标题没写。以这类数据包的常见做法来看，一般会包含下面几类信息：

这张表的用意是帮你建立预期，不是背字段名。导入之后先执行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文件放到服务器上，或者文件到了几百MB，source的交互式体验反而碍事，直接用shell重定向更稳。

# 用mysql命令重定向导入，数据不会经过客户端交互界面 mysql -u root -p --default-character-set=utf8mb4 tour_db < tour_city.sql # 如果导出SQL时用了local-infile，导入时也要对应放开 mysql -u root -p --default-character-set=utf8mb4 \ --local-infile=1 tour_db < tour_city.sql

参数解释：--default-character-set=utf8mb4和刚才的SET NAMES作用一致，只不过是在连接阶段生效；<是shell重定向，把SQL文件内容作为标准输入喂给mysql进程；--local-infile=1只在脚本里用了LOAD DATA LOCAL INFILE时才需要，如果脚本是纯INSERT，可以不加。

重定向导入的好处是：不用守着交互界面、退出终端也不影响、适合写进部署脚本。坏处是：看不到逐条执行进度，如果出错也不知道停在哪。所以重定向导入的时候，务必加日志记录。

3.4 导入日志是最后的后悔药

我自己的习惯是无论哪种方式导入，都把输出落盘。这样即便过了一天才发现数据有问题，也能通过日志定位到当时报错的位置，不用重新猜。

# 带日志导入，-vvv输出详细执行信息 mysql -u root -p --default-character-set=utf8mb4 \ --show-warnings -vvv tour_db < tour_city.sql \ > import.log 2>&1 # 导入完成后检查错误 grep -i "error" import.log | head -20 # 看最后几行确认执行结果 tail -n 20 import.log

-vvv是verbosity级别，控制台会打印比较详细的执行信息，配合2>&1把标准错误也重定向到同一个日志文件。--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和Praha），GROUP 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-set=utf8mb4；用图形工具的话，把连接属性里的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-packet=64M。注意：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-set=utf8mb4 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看编码开头。这三步用到现在，救回过不少差点被覆盖的本地表。做数据整合这行，稳永远比快重要。希望帮到你。

本文还有配套的精品资源，点击获取