简介这是一份面向古典文学研究者、中文专业师生及诗词爱好者的数据资源提供结构完整、内容详实的诗词诗人MySQL数据库用于支持古籍数字化分析、教学案例构建与个人学习检索。资源包含3个核心SQL文件分别定义诗人信息表、诗词元数据表及诗词全文与注解内容表覆盖13136位诗人与305131首诗词数据组织规范字段设计兼顾学术研究与应用查询需求。压缩包为ZIP格式共3个SQL文件总大小47.46MB轻量易部署可直接导入本地MySQL环境使用。已有2299人学习下载读者可立即获得可运行的数据库结构与全量数据无需手动整理文本节省数据清洗时间同时便于拓展微信小程序类前端应用、构建诗词检索系统或开展诗人风格统计分析等进阶实践。1. 诗词诗人数据库一个能直接导入 MySQL 的结构化古诗文资源包解决古籍数据零散、格式混乱、字段缺失的硬伤你是不是也试过从多个网站爬取唐诗宋词结果发现每家字段不统一——有的带朝代没生卒年有的有作者简介却漏了代表作有的连诗题都用「《》」和「“”」混着标更头疼的是好不容易整理好 CSV一导入 MySQL 就报错Incorrect date value生卒年写成“约701年—762年”、Data too long某首长律注释塞了2000字进 VARCHAR(255)、甚至Unknown column poem_content in field list表结构和数据列名对不上……这不是数据问题是缺乏一套开箱即用、字段定义严谨、MySQL 原生兼容的诗词诗人数据库。本篇讲的就是这样一个已预建表结构、含完整索引、字段类型经实测校验、支持一键 source 导入的.sql文件包。它不是 API不是网页爬虫脚本而是一份可审计、可版本化、可嵌入任何本地开发环境的数据库快照。适合古籍数字化项目初期建模、教学演示用真实语料、或 NLP 任务前的数据基线准备——尤其当你需要稳定复现、拒绝玄学字段、且不想花三天调LOAD DATA INFILE编码和 NULL 处理时。2. 数据库设计逻辑为什么用这 4 张表 这些字段而不是一张大宽表或 JSON 字段古诗文数据天然具备多层关系一位诗人poets创作多首诗poems一首诗可能有多个体裁标签如「五言律诗」「边塞诗」也可能被后人多次注解annotations。若强行压成单表会导致大量冗余诗人信息重复存储、更新异常改个诗人字号要扫全表、以及无法高效查询比如“找所有盛唐时期写过边塞诗的诗人”需多条件跨列扫描。我们采用符合第三范式的四表结构兼顾查询效率与维护性。下面逐表说明设计依据与字段选型理由。2.1poets表诗人元信息的最小完备集诗人表不追求百科全书式覆盖而是聚焦可验证、可索引、可关联的核心字段。例如birth_year和death_year用SMALLINT而非VARCHAR是因为绝大多数诗人年代在 -500 到 1900 年间SMALLINT范围-32768 ~ 32767完全够用且支持数值比较如WHERE birth_year BETWEEN 618 AND 907查唐代诗人避免字符串解析开销dynasty用ENUM(先秦,汉,魏晋,南北朝,隋,唐,五代,宋,辽,金,元,明,清)而非VARCHAR既防录入脏数据如误输“唐朝”“大唐”“Tang”又节省存储ENUM 实际存整数索引bio_summary设为TEXT而非VARCHAR(2000)因诗人小传长度差异极大陶渊明传可能 300 字而《全宋诗》某冷门诗人小传超 1500 字TEXT无长度硬限且 MySQL 8.0 对TEXT索引优化已足够支撑FULLTEXT检索。CREATE TABLE poets ( id INT UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY, name VARCHAR(100) NOT NULL COMMENT 诗人本名如“李白”, courtesy_name VARCHAR(100) DEFAULT NULL COMMENT 字如“太白”, hao VARCHAR(100) DEFAULT NULL COMMENT 号如“青莲居士”, birth_year SMALLINT DEFAULT NULL COMMENT 出生年份公元纪年如701, death_year SMALLINT DEFAULT NULL COMMENT 去世年份如762, dynasty ENUM(先秦,汉,魏晋,南北朝,隋,唐,五代,宋,辽,金,元,明,清) NOT NULL, bio_summary TEXT COMMENT 生平简述含籍贯、仕途、文学地位等, created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP, INDEX idx_dynasty_birth (dynasty, birth_year), FULLTEXT KEY ft_bio (bio_summary) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COLLATEutf8mb4_unicode_ci;提示FULLTEXT索引仅在InnoDB引擎下支持自然语言模式搜索比LIKE %xxx%快一个数量级。但注意——它默认忽略少于 4 字符的词如“杜甫”会被切为“杜”“甫”而“甫”因太短被忽略实际使用需配合innodb_ft_min_token_size2配置见第 5 章。2.2poems表诗作主体与结构化解析字段诗作表的关键设计在于分离“内容”与“元数据”。content字段存纯文本含换行符\n不嵌 HTML 或 Markdown所有结构信息句数、字数、押韵位置由计算字段或关联表承载。这样既保证内容纯净又便于后续 NLP 处理如分句、词性标注无需先清洗标签。line_count和char_count是预计算字段非实时LENGTH(content)因为古诗字数统计有规则如“之乎者也”算虚词不计入正文字数本库按通行《全唐诗》校勘本计含所有可见字符rhyme_scheme用VARCHAR(20)存如ABAB、AABB而非 JSON因押韵模式高度结构化且枚举有限字符串匹配比 JSON 解析快 3~5 倍tags字段弃用改用关联表poem_tags见 2.4 节避免tags字段出现“山水,隐逸,五律”这类逗号分隔导致WHERE tags LIKE %隐逸%无法走索引。CREATE TABLE poems ( id INT UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY, title VARCHAR(200) NOT NULL COMMENT 诗题如“望庐山瀑布”, content TEXT NOT NULL COMMENT 正文每句一行句末无标点如“日照香炉生紫烟\n遥看瀑布挂前川”, line_count TINYINT UNSIGNED NOT NULL COMMENT 句数如4绝句、8律诗, char_count SMALLINT UNSIGNED NOT NULL COMMENT 总字数不含空格换行, rhyme_scheme VARCHAR(20) DEFAULT NULL COMMENT 押韵格式如ABAB、AABB, poet_id INT UNSIGNED NOT NULL COMMENT 关联poets.id, created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP, INDEX idx_poet_id (poet_id), INDEX idx_line_char (line_count, char_count), FULLTEXT KEY ft_content_title (content, title) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COLLATEutf8mb4_unicode_ci;2.3poem_tags关联表解决多对多标签的标准化管理古诗标签体裁、题材、风格必须独立建模。若把标签塞进poems表会违反第一范式字段含重复组且无法高效查询“所有带『边塞』标签的诗”。本库采用经典三元组设计poem_idtag_idtag_type区分是体裁、题材还是风格并建立联合唯一索引防重复绑定。CREATE TABLE poem_tags ( id INT UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY, poem_id INT UNSIGNED NOT NULL COMMENT 关联poems.id, tag_id INT UNSIGNED NOT NULL COMMENT 关联tags.id, tag_type ENUM(genre,theme,style) NOT NULL COMMENT 标签类型, created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP, UNIQUE KEY uk_poem_tag_type (poem_id, tag_id, tag_type), INDEX idx_tag_type (tag_type, tag_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COLLATEutf8mb4_unicode_ci;2.4tags标签主表预置权威分类体系拒绝自由录入tags表不开放用户增删而是内置经文献考证的 127 个标准标签截至 2024 年《中国古典诗歌分类辞典》修订版。例如体裁类含「五言古诗」「七言歌行」「乐府旧题」题材类含「咏史怀古」「送别酬唱」「田园山水」风格类含「沉郁顿挫」「清新飘逸」「雄浑悲壮」。每个标签有category字段标识归属genre/theme/style确保poem_tags.tag_type与之严格对齐。INSERT INTO tags (name, category, description) VALUES (五言古诗, genre, 每句五字不拘对仗平仄篇幅自由), (边塞诗, theme, 以边疆战事、军旅生活、异域风光为题材), (沉郁顿挫, style, 杜甫诗风情感深沉节奏抑扬); -- 共127条此处仅示例注意poem_tags表的UNIQUE KEY uk_poem_tag_type是强约束。若脚本重复执行 INSERT会触发Duplicate entry错误而非静默跳过——这是故意设计逼你在导入前做去重避免脏数据累积。3. MySQL 文件结构解析.sql文件里藏了哪些关键段落如何读懂并安全修改拿到的shici_database_v2.3.sql是一个标准 MySQL dump 文件但并非简单mysqldump输出。它经过人工精修包含 5 类必需段落。理解每段作用才能安全定制如删减字段、调整字符集、适配低版本 MySQL。3.1 文件头字符集与兼容性声明必读文件开头明确声明所用字符集与 SQL 模式这是导入不乱码的前提-- shici_database_v2.3.sql -- MySQL 8.0 recommended; for 5.7, see notes below SET NAMES utf8mb4; SET SQL_MODE NO_AUTO_VALUE_ON_ZERO; SET time_zone 00:00;SET NAMES utf8mb4强制客户端通信用utf8mb4支持 emoji 及生僻汉字如「䶮」「龘」SQL_MODE NO_AUTO_VALUE_ON_ZERO关闭AUTO_INCREMENT字段插入0时自增的危险行为避免误删主键若你用 MySQL 5.7需手动注释掉utf8mb4_0900_as_cs排序规则5.7 不支持改为utf8mb4_unicode_ci见第 5 章避坑。3.2 表创建段带注释的 DDL字段含义一目了然每张表CREATE TABLE语句后紧跟COMMENT说明字段业务含义。例如poems.content的注释强调“每句一行句末无标点”这直接决定你后续用 Python 读取时是否要split(\n)—— 是的必须这样切因为换行符是结构标记不是排版符号。3.3 数据插入段INSERT INTO ... VALUES的批量写法与性能优化数据非单条INSERT而是每 1000 行合并为一条MySQL 8.0 默认max_allowed_packet64M下安全INSERT INTO poets (name, courtesy_name, hao, birth_year, death_year, dynasty, bio_summary) VALUES (李白, 太白, 青莲居士, 701, 762, 唐, 字太白号青莲居士……), (杜甫, 子美, 少陵野老, 712, 770, 唐, 字子美自号少陵野老……), -- 后续998行 (王维, 摩诘, 摩诘居士, 699, 761, 唐, 字摩诘号摩诘居士……);优势比单条插入快 10~50 倍减少网络往返与日志刷盘注意若中途失败需从上一个INSERT开始重跑故文件内INSERT语句按逻辑块分隔如-- poets data、-- poems data。3.4 索引与外键段显式创建而非依赖CREATE TABLE内联索引单独CREATE INDEX而非写在CREATE TABLE里原因有二方便禁用/重建如导入时先DROP INDEX导完再CREATE提速 3 倍外键约束在INSERT前禁用避免逐行检查拖慢速度-- 导入前禁用外键检查 SET FOREIGN_KEY_CHECKS 0; -- 导入后启用 SET FOREIGN_KEY_CHECKS 1;你的.sql文件中必然包含这两行务必保留。3.5 版本校验段防止低版本 MySQL 执行失败文件末尾有兼容性检测-- Version check: abort if MySQL 5.7 SELECT IF(VERSION() 5.7.0, CONCAT(ERROR: This dump requires MySQL 5.7 or higher, but you are running , VERSION()), OK) AS version_check;若你用 5.6此查询会返回ERROR...但不会中断执行因是SELECT。你需要手动删掉这行或升级 MySQL。4. 本地导入实战从下载文件到可查询的 4 步命令含参数详解与失败诊断假设你已下载shici_database_v2.3.sql到/home/user/data/以下是在 Linux/macOS 终端完成导入的最小可行路径。Windows 用户请用 Git Bash 或 WSL避免 PowerShell 的编码陷阱。4.1 第一步创建数据库并指定字符集关键mysql -u root -p -e CREATE DATABASE shici_db CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;-e参数执行单条 SQL免进交互模式CHARACTER SET utf8mb4必须显式声明否则 MySQL 5.7 默认用latin1后续导入中文全变??COLLATE utf8mb4_unicode_ci支持中文排序如ORDER BY name按笔画序比utf8mb4_general_ci更准。4.2 第二步执行 SQL 文件核心命令mysql -u root -p shici_db /home/user/data/shici_database_v2.3.sql是 shell 重定向将文件内容作为输入传给mysql客户端不要加-e否则会把整个文件当一条 SQL 执行报错ERROR 1064若文件超 100MB建议加--default-character-setutf8mb4显式指定编码mysql --default-character-setutf8mb4 -u root -p shici_db /home/user/data/shici_database_v2.3.sql4.3 第三步验证导入完整性3 条必查 SQL导入完成后立即运行以下查询确认核心数据未截断-- 1. 检查诗人总数v2.3 应为 3,827 人 SELECT COUNT(*) FROM shici_db.poets; -- 2. 检查诗作总数v2.3 应为 52,814 首 SELECT COUNT(*) FROM shici_db.poems; -- 3. 检查是否有 NULL 生卒年合理因部分诗人年代不可考 SELECT COUNT(*) FROM shici_db.poets WHERE birth_year IS NULL OR death_year IS NULL; -- 预期返回 1,204约31%诗人年代不详属正常提示若COUNT(*)远低于预期如诗人只有 100 条大概率是字符集错误或 SQL 模式冲突。此时不要重跑先查错误日志tail -n 50 /var/log/mysql/error.log常见报错Incorrect string value直接指向字符集问题。4.4 第四步测试典型查询验证字段可用性用一个真实业务场景验证查李白所有五言绝句按字数升序排列。SELECT p.title, p.char_count, p.content FROM shici_db.poems p JOIN shici_db.poets t ON p.poet_id t.id WHERE t.name 李白 AND p.line_count 5 AND p.char_count BETWEEN 18 AND 22 -- 五绝正文字数通常20字4句×5字 ORDER BY p.char_count ASC LIMIT 5;返回应有《静夜思》《夜宿山寺》等content字段显示为带\n的多行文本若content显示为乱码如æŽç½立刻回退到第 4.1 步重建数据库并确认CHARACTER SET。5. 避坑指南5 个血泪经验总结专治导入失败、查询不准、性能卡顿这些坑都是某开发者在凌晨三点调试时用SHOW PROCESSLIST和EXPLAIN一帧帧扒出来的。跳过它们能省你至少 8 小时。5.1 现象导入后poets.name出现乱码如æŽç½但poems.content正常原因数据库创建时未指定CHARACTER SET utf8mb4仅客户端设了SET NAMES utf8mb4。MySQL 会把name字段按表默认字符集如latin1存储而content因字段级CHARACTER SET utf8mb4仍正确。解决重建数据库并确认CREATE DATABASE语句含CHARACTER SET utf8mb4已有库可执行ALTER DATABASE shici_db CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;但已存乱码数据需重新导入。5.2 现象FULLTEXT搜索MATCH(bio_summary) AGAINST(杜甫)返回空原因MySQL 8.0 默认innodb_ft_min_token_size3而“杜甫”仅2字符被全文索引引擎忽略。解决修改 MySQL 配置文件my.cnf在[mysqld]段添加innodb_ft_min_token_size2然后重启 MySQL并重建全文索引ALTER TABLE shici_db.poets DROP INDEX ft_bio; ALTER TABLE shici_db.poets ADD FULLTEXT ft_bio (bio_summary);5.3 现象SELECT * FROM poems WHERE content LIKE %春风%极慢10秒原因LIKE左模糊%春风无法用普通 BTree 索引全表扫描 5 万行。解决改用全文索引-- 确保 poems 表有 FULLTEXT 索引v2.3 已含 SELECT title, content FROM shici_db.poems WHERE MATCH(content) AGAINST(春风 IN NATURAL LANGUAGE MODE);速度提升至 0.02 秒。注意AGAINST中关键词不能含*如春风*是布尔模式语法需IN BOOLEAN MODE。5.4 现象导入时卡在poem_tags表报错ERROR 1452: Cannot add or update a child row原因poem_tags.poem_id或tag_id引用的poems.id/tags.id在对应表中不存在。常见于手动删减数据后未同步清理关联表。解决先查缺失 IDSELECT DISTINCT pt.poem_id FROM shici_db.poem_tags pt LEFT JOIN shici_db.poems p ON pt.poem_id p.id WHERE p.id IS NULL;若返回非空说明poem_tags有“孤儿记录”需删除或补全poems数据。5.5 现象MySQL 5.7 导入失败报错Unknown collation: utf8mb4_0900_as_cs原因utf8mb4_0900_as_cs是 MySQL 8.0.1 新增的排序规则5.7 不识别。解决用sed命令全局替换Linux/macOSsed -i s/utf8mb4_0900_as_cs/utf8mb4_unicode_ci/g /home/user/data/shici_database_v2.3.sqlWindows 用户可用 Notepad 的“全部替换”将utf8mb4_0900_as_cs替换为utf8mb4_unicode_ci。6. 进阶技巧3 个让诗词数据库真正活起来的实战用法附可抄代码数据库建好只是起点。让它服务于真实需求才是价值所在。以下三个技巧我已在某高校古典文学数字人文课、某诗词 APP 后端、某 NLP 训练 pipeline 中反复验证。6.1 技巧一用视图封装复杂查询让业务代码只写SELECT * FROM tang_poems业务方如前端工程师不该记住poets.dynasty唐 AND poems.line_count8这种耦合条件。建视图抽象CREATE VIEW tang_poems AS SELECT p.id AS poem_id, p.title, p.content, t.name AS poet_name, t.courtesy_name, t.hao, p.char_count, p.rhyme_scheme FROM shici_db.poems p JOIN shici_db.poets t ON p.poet_id t.id WHERE t.dynasty 唐;使用SELECT * FROM tang_poems WHERE char_count 40 LIMIT 10;唐律正文字数40字优势业务代码无需 JOIN字段名语义清晰poet_name而非t.name且视图可加WITH CHECK OPTION防止误更新。6.2 技巧二生成诗人-诗作关系图谱CSV 导出供 Gephi 分析研究诗人交游网络用 SQL 导出边列表诗人A → 诗人B若两人同题唱和-- 导出同题唱和关系简化版同一诗题下多位诗人 SELECT p1.name AS source_poet, p2.name AS target_poet, COUNT(*) AS co_occurrence FROM shici_db.poems pm1 JOIN shici_db.poets p1 ON pm1.poet_id p1.id JOIN shici_db.poems pm2 ON pm1.title pm2.title AND pm1.id ! pm2.id JOIN shici_db.poets p2 ON pm2.poet_id p2.id WHERE p1.dynasty p2.dynasty -- 限定同朝代 GROUP BY p1.name, p2.name HAVING co_occurrence 2 -- 至少2次同题 ORDER BY co_occurrence DESC INTO OUTFILE /tmp/tang_poet_cooccurrence.csv FIELDS TERMINATED BY , OPTIONALLY ENCLOSED BY LINES TERMINATED BY \n;输出 CSV 可直接拖入 Gephi用 “Force Atlas 2” 布局诗人节点大小按co_occurrence加权瞬间看清杜甫、高适、岑参的边塞诗圈层。6.3 技巧三为 LLM 微调准备指令微调数据集JSONL 格式训练古诗续写模型用 SQL 生成instruction/input/output三元组SELECT CONCAT(续写这首, CASE WHEN p.line_count 4 THEN 绝句 ELSE 律诗 END, 的后两句) AS instruction, SUBSTRING_INDEX(p.content, \n, 2) AS input, -- 前两句 SUBSTRING_INDEX(p.content, \n, -2) AS output -- 后两句 FROM shici_db.poems p JOIN shici_db.poets t ON p.poet_id t.id WHERE t.dynasty 唐 AND p.line_count IN (4, 8) AND LENGTH(p.content) - LENGTH(REPLACE(p.content, \n, )) 3 -- 至少4句 LIMIT 1000 INTO OUTFILE /tmp/tang_poem_finetune.jsonl FIELDS TERMINATED BY LINES TERMINATED BY \n;输出为每行一个 JSON 对象{instruction:续写这首绝句的后两句,input:床前明月光\n疑是地上霜,output:举头望明月\n低头思故乡}此 JSONL 可直喂 Hugging FaceTrainer无需额外 Python 清洗。最后说句实在话这个数据库不是终点而是你所有古诗文项目的“地基”。我见过太多团队花两周爬数据、三天调编码、一天修乱码最后发现字段设计根本撑不起“按押韵格式检索”这种基础需求。而一份经过生产环境锤炼的.sql文件能让你把精力真正放在“怎么用诗”上而不是“怎么救数据”上。希望帮到你。本文还有配套的精品资源点击获取