简介这份资源是面向诗词爱好者、文学研究者与网站开发者的MySQL数据库数据包将古典诗词与诗人信息整理成结构化表格支持按作者、朝代、体裁、韵律等条件快速筛选检索适用于教学演示、学术研究和搭建古诗词查询系统。压缩包共3个SQL脚本文件体积47.46MB分别负责创建诗词基本信息表、诗词正文与注释赏析表、诗人档案表通过主外键关联即可还原作品与作者的完整关系导入MySQL后可直接使用。数据内含13136位诗人与305131首诗词覆盖字号、生卒年、籍贯、仕途等字段并配套搜索小程序可即时查看原文及专家点评方便横向对比不同年代的创作脉络。目前已有2298人学习下载这套数据既能用于中文信息处理和文学数据可视化也可作为个人诗词库的底层数据实用价值较高。1. 诗词诗人数据库是什么一份能直接导入的MySQL数据包拿到“诗词诗人数据库.mysql”这类文件的人多半不是想研究建表理论而是想让本地MySQL里立刻出现一张能查的诗词表输入朝代返回诗人列表输入关键词命中诗句输入诗人姓名拉出全集。这份文件本质上就是一套mysqldump导出结果里面是建表语句和INSERT数据后缀叫.sql还是.mysql并不重要能不能顺利导入并查对才是关键。它能解决三类需求离线检索不用联网、结构化地关联诗人与作品、给课程设计和古诗词语料分析提供干净数据源。适合正在学MySQL的初学者、做中文NLP分词预处理的研究者以及想两天内搭出诗词查询站点的开发者。2. 拆开数据模型三张表设计与建表SQL跑通第一遍2.1 为什么诗人、诗词、分类要拆成三张表很多第一次接触诗词数据库的人会问一张表里塞下“诗名、正文、作者、朝代、分类”不是更省事吗省事是真的但灾难也是真的。拿李白来说他写了上千首诗如果把姓名和朝代字段重复放进每一首诗的记录里数据冗余会膨胀得很厉害哪天想把“李白”的朝代从“唐”改成“盛唐”得同时更新上千条记录漏掉一条就产生脏数据。更麻烦的是一首诗只有一个作者但一个作者有大量诗这是典型的1:N关系不该平铺在一张表里。常见做法是拆成三张核心表poets存诗人信息poems存诗词正文categories存分类。诗人与诗词通过author_id关联诗词与分类通过category_id关联。这样李白的信息只存一次poems表里每条记录只存一个整数ID来指向李白既省空间又方便统计。如果未来想支持“一首诗属于多个分类”只需要再加一张关联表而不是改动已有表结构。2.2 一份可以直接执行的建表SQL我一般会先重建这三张表再把数据导进去。下面的脚本可以直接在MySQL客户端执行逻辑上对应大多数诗词库文件的结构CREATE DATABASE IF NOT EXISTS poetry_db DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; USE poetry_db; CREATE TABLE poets ( id INT UNSIGNED NOT NULL AUTO_INCREMENT COMMENT 诗人ID, name VARCHAR(50) NOT NULL COMMENT 诗人姓名, dynasty VARCHAR(50) DEFAULT NULL COMMENT 朝代, alias VARCHAR(100) DEFAULT NULL COMMENT 字、号, birth_year INT DEFAULT NULL COMMENT 出生年份不详则为NULL, intro TEXT COMMENT 人物简介, PRIMARY KEY (id), KEY idx_dynasty (dynasty), KEY idx_name (name) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT诗人表; CREATE TABLE categories ( id TINYINT UNSIGNED NOT NULL AUTO_INCREMENT COMMENT 分类ID, name VARCHAR(50) NOT NULL COMMENT 分类名, PRIMARY KEY (id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT诗词分类表; CREATE TABLE poems ( id INT UNSIGNED NOT NULL AUTO_INCREMENT COMMENT 诗词ID, title VARCHAR(255) NOT NULL COMMENT 诗词题目, author_id INT UNSIGNED NOT NULL COMMENT 作者ID关联poets.id, category_id TINYINT UNSIGNED DEFAULT NULL COMMENT 分类ID关联categories.id, content TEXT NOT NULL COMMENT 诗词正文, created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP COMMENT 入库时间, PRIMARY KEY (id), KEY idx_author (author_id), KEY idx_category (category_id), CONSTRAINT fk_poems_author FOREIGN KEY (author_id) REFERENCES poets (id), CONSTRAINT fk_poems_category FOREIGN KEY (category_id) REFERENCES categories (id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT诗词表;这段SQL做了三件关键事第一把数据库默认字符集设为utf8mb4保证中文和生僻字不丢第二poets和poems通过外键关联避免插入不存在作者的脏数据第三在dynasty、name、author_id、category_id上建了普通索引因为这几个字段是后续查询的过滤条件。执行时如果服务器已经存在同名表先手动确认是否需要备份再决定是否加DROP TABLE IF EXISTS。2.3 字段类型与索引四个最容易改错的地方id用INT UNSIGNED而不是INTUNSIGNED让可存储的正数范围翻倍诗词库的量级远不会触及上限但多留余地没有坏处AUTO_INCREMENT保证新增记录不冲突。content用TEXT而不是VARCHAR一首律诗八十多个字一首排律或词可能几百字VARCHAR(255)放不下长调改成VARCHAR(2000)又浪费空间。TEXT按需存储更适合不定长正文。authors表的name不建唯一索引同名的诗人不止一个比如唐代有多个“李益”宋代有多个“王灼”。一旦建了唯一索引导入时碰到重名直接报错整个导入流程卡死。所以name用普通索引允许重复。外键不是越多越好外键能保护数据完整性但会让INSERT和DELETE变慢而且导入顺序错乱时会报外键约束错误。如果这份MySQL文件只做查询展示不涉及频繁写入可以把外键去掉只保留普通索引性能会更好。3. 把sql文件导入本地MySQLsource与工具两条路3.1 导入前先把环境和字符集对齐不少人下载完MySQL安装教程看完就动手结果第一步就翻车服务没起来客户端连不上去报错“Cant connect to local MySQL server through socket”。导入之前先用一条命令确认mysqld进程在跑systemctl status mysqld如果没安装或者版本太老先解决安装问题再看导入。接下来确认客户端字符集和文件编码一致。用文本编辑器打开这份MySQL文件或者用file命令看编码file 诗词诗人数据库.sql常见结果有两种UTF-8或者GBK。大多数诗词库文件是UTF-8所以客户端连接时要主动声明mysql -uroot -p --default-character-setutf8mb4这一步不做后面的中文十有八九变乱码。GBK编码的文件则需要先把文件转成UTF-8或者让连接字符集跟随文件编码二选一绝不能混用。3.2 用source命令导入并实时看报错启动MySQL客户端并进入poetry_db后直接用source执行文件。source的好处是逐条执行遇到错误会在屏幕上打印行号和原因方便定位烂数据USE poetry_db; SOURCE /data/sql/诗词诗人数据库.sql;如果文件路径含中文确保客户端本身的系统字符集支持否则会把路径解析错。导入过程中眼睛盯住两样东西ERROR开头的行以及最后出现的“Query OK”数量。不要看滚动速度要看有没有红色的报错。想跳过交互直接执行可以把source命令写成管道mysql -uroot -p --default-character-setutf8mb4 /data/sql/诗词诗人数据库.sql这种方式适合反复测试的自动化流程但报错信息不如交互式source直观新手第一次导入建议还是走SOURCE。3.3 用Navicat等图形化工具导入图形工具是绝大多数非命令行用户的首选Navicat算是这一类里最常被搜到的。操作路径很固定先新建连接填主机、端口、用户名和密码测试连接成功然后在左侧连接下新建数据库poetry_db字符集选utf8mb4右键这个数据库选“运行SQL文件”弹出窗口里选中你的诗词MySQL文件点开始。注意底部有个“遇到错误时继续”的开关第一次导入不要勾选否则错误会淹没在大量成功输出里事后数据缺失都查不出来。Navicat这类工具还会遇到一个隐蔽问题默认的max_allowed_packet太小导入时碰到很长的INSERT语句会中断报错提示是“Got a packet bigger than max_allowed_packet bytes”。解决办法是在连接上执行下面这句然后重连SET GLOBAL max_allowed_packet 128 * 1024 * 1024;设置完确认一下生效SHOW VARIABLES LIKE max_allowed_packet; 不是128M就重新连接再查。4. 查询实战按诗人、朝代、关键词检索出数据4.1 最常用的三连查诗人信息、作品列表、单篇正文数据导入完成后把接口接起来之前先验证三件事能不能按名字查到诗人能不能按诗人查出作品列表能不能点开作品看到完整正文。这三条SQL是诗词库最核心的查询模式也是后面做接口的基石。查诗人基本信息SELECT id, name, dynasty, alias, birth_year FROM poets WHERE name 李白;按诗人查作品列表需要JOIN两张表用author_id建立关联SELECT p.id, p.title, c.name AS category_name FROM poems p LEFT JOIN categories c ON p.category_id c.id WHERE p.author_id 1 ORDER BY p.id DESC LIMIT 50;查单篇完整正文直接命中poems主键速度最快SELECT po.name, po.dynasty, p.title, p.content FROM poems p JOIN poets po ON p.author_id po.id WHERE p.id 1024;三条语句分别覆盖了等值查询、JOIN查询和主键查询。注意第二条的LIMIT 50李白全集上千首不限制的话结果集太大网络传输和前端渲染都会卡。实际做接口时还要加分页参数用LIMIT offset, count实现。4.2 关键词模糊匹配与中文全文索引诗词库里最常被问到的需求是“帮我找一句诗我记得里面有明月”。这要用LIKE做模糊查询SELECT title, content FROM poems WHERE content LIKE %明月% LIMIT 20;数据量几千条时LIKE还能接受超过几万条就开始明显变慢因为LIKE前置通配符会让索引失效MySQL只能全表扫描。这时更专业的做法是上全文索引。MySQL 5.7和8.0都支持中文全文索引前提是用ngram解析器ALTER TABLE poems ADD FULLTEXT INDEX ft_content (content) WITH PARSER ngram; SELECT id, title, content FROM poems WHERE MATCH(content) AGAINST(明月 IN NATURAL LANGUAGE MODE) LIMIT 20;ngram把中文切成长度为2的词元适合诗词这种短文本检索。如果要调整最小分词长度可以在MySQL配置的mysqld段加ngram_token_size2然后重启服务。这个参数默认就是2对唐诗宋词基本够用不需要特殊优化。4.3 统计与自查朝代分布、空值、重复数据拿到新数据库第一件事不该是急着写业务代码而是先把数据质量摸个底。统计诗人按朝代的分布SELECT dynasty, COUNT(*) AS poet_count FROM poets GROUP BY dynasty ORDER BY poet_count DESC;检查诗词表是否存在孤儿数据也就是author_id在poets里找不到对应记录SELECT p.id, p.title, p.author_id FROM poems p LEFT JOIN poets po ON p.author_id po.id WHERE po.id IS NULL LIMIT 10;有孤儿数据说明这份MySQL文件本身有外键缺失或者导入时没按正确顺序执行。再查重复标题和重复正文SELECT title, COUNT(*) AS cnt FROM poems GROUP BY title HAVING cnt 1 ORDER BY cnt DESC LIMIT 20;如果重复记录很多需要写清洗脚本统一去重而不是手工删。去重时保留id最小的那条其余删除一条SQL就能完成DELETE p1 FROM poems p1 JOIN poems p2 ON p1.title p2.title AND p1.author_id p2.author_id AND p1.id p2.id;5. 避坑指南导入报错、中文乱码与数据质量处理的实战记录5.1 导入时报错ERROR 1064语法错误文件头藏了BOM现象source执行时前几行就报ERROR 1064 (42000): You have an error in your SQL syntax文件一开始就是CREATE TABLE语句看不出任何问题。原因文件用记事本或Windows编辑器保存成带UTF-8 BOM的编码BOM这个不可见字符混进了SQL语句的起始位置导致MySQL解析第一个关键词失败。解决用Notepad或VS Code打开文件把编码转成“UTF-8无BOM”后另存再重新导入。这是Windows下载的SQL文件最常见的坑没有之一。5.2 中文导入后全是问号连接字符集没对齐现象导入成功SELECT查询出来的诗人名是“????”正文全是问号。原因文件本身是GBK或UTF-8中文但客户端连接MySQL时用了latin1导致中文在写入时被错误转码。解决先确认真实编码用file命令查一遍然后指定连接字符集重新导入。如果数据已经成了乱码不要再重复导入先把现有表清空再带字符集参数重导。已经存进去的脏数据不要试图用UPDATE反转SQL层面处理乱码纯靠玄学直接清掉重来是最省时的。5.3 ERROR 2002连不上本地socket服务或路径不对现象mysql -uroot -p执行后报ERROR 2002 (HY000): Cant connect to local MySQL server through socket /tmp/mysql.sock。原因mysqld服务没有启动或者编译安装的MySQL socket文件路径不在/var/lib/mysql下。解决先启动服务CentOS等Linux发行版执行systemctl start mysqld如果服务已在运行还报错执行mysql -uroot -p -h 127.0.0.1 -P 3306走TCP协议绕开socket文件路径问题。5.4 大文件导入断在max_allowed_packet太小现象导入到一半中断报错Got a packet bigger than max_allowed_packet bytes。原因诗词正文里偶尔有超长记录单条INSERT的SQL文本长度超过默认的4M或16M限制。解决进入MySQL执行SET GLOBAL max_allowed_packet128M然后断开重连。注意这个参数是全局的但当前连接不会立刻生效必须重新登录。如果是图形化工具导入还要检查工具自带的“高级”设置里有没有单独的包大小限制。5.5 重复导入导致主键冲突和数据翻倍现象同一份SQL文件导了两次第一次成功第二次中途报主键冲突。原因文件里没有DROP TABLE IF EXISTS语句第二次执行时旧数据还在INSERT碰到相同主键直接报错。解决导入前先手动执行DROP TABLE IF EXISTS poems、poets、categories注意外键约束要求先删子表poems再删父表顺序反过来会报错。如果已经导入成功但想清空重来用TRUNCATE TABLE比DELETE快而且能重置自增ID。养成导入前检查文件头有没有DROP语句的习惯能省掉后面一大半麻烦。6. 把诗词库做成一个可调用的查询接口数据导入并验证无误后下一步自然是把它暴露成接口给前端页面或者其他程序调用。我用Flask写一个最小查询接口连上MySQL接收诗人名、朝代、关键词三个参数返回匹配的诗词列表。这个结构可以直接跑通再往上层加搜诗页和随机推荐都容易。from flask import Flask, request, jsonify import pymysql app Flask(__name__) DB_CONFIG { host: 127.0.0.1, port: 3306, user: root, password: 你的密码, database: poetry_db, charset: utf8mb4, cursorclass: pymysql.cursors.DictCursor, } def connect(): return pymysql.connect(**DB_CONFIG) app.route(/api/poems, methods[GET]) def search_poems(): poet request.args.get(poet, ) keyword request.args.get(keyword, ) dynasty request.args.get(dynasty, ) sql ( SELECT po.name, po.dynasty, p.title, p.content FROM poems p JOIN poets po ON p.author_id po.id WHERE 11 ) params [] if poet: sql AND po.name LIKE %s params.append(f%{poet}%) if dynasty: sql AND po.dynasty %s params.append(dynasty) if keyword: sql AND p.content LIKE %s params.append(f%{keyword}%) sql ORDER BY po.id, p.id DESC LIMIT 50 conn connect() try: with conn.cursor() as cur: cur.execute(sql, params) rows cur.fetchall() return jsonify({total: len(rows), items: rows}) finally: conn.close() if __name__ __main__: app.run(host0.0.0.0, port5000, debugTrue)这段代码有四个细节值得注意WHERE 11是拼SQL的惯用技巧后面的条件可以无脑追加不用判断是不是第一个条件所有查询参数都用%s占位符传入杜绝SQL注入风险conn关闭放在finally里保证即使查询异常也不泄漏连接LIMIT 50返回上限避免恶意请求拉爆内存。启动后访问http://127.0.0.1:5000/api/poems?poet李白keyword明月就能看到JSON格式的诗句结果。验证接口是否正常可以用curl打一发请求curl http://127.0.0.1:5000/api/poems?poet苏轼dynasty宋。如果返回了苏轼的诗词列表说明从SQL文件导入到后端接口的整条链路已经通了。我自己的习惯是先做一条只返回标题的接口验证连通性再逐步加正文、分页、排序这些功能这样每步排错范围都很小。这个方向真正值得投入的地方不在导入这一步而在后续怎么清洗、去重、关联出更高质量的语料库那才是诗词数据应用里最花时间也最出价值的部分。希望帮到你。本文还有配套的精品资源点击获取