简介这是一份面向古诗词研究爱好者、数据分析师及教育工作者的中华古诗词数据库资源收录先秦至近现代的24193条诗词记录覆盖多朝代作者与作品可用于诗词特征分析、创作规律挖掘、朝代主题演化研究及诗词教学设计。压缩包共8个文件整体约10.21MB提供SQL、JSON、CSV、XLSX四种主流格式SQL便于数据库查询统计JSON适合程序化解析与文本挖掘CSV可直接用表格软件打开浏览XLSX支持在Excel中筛选、计算与图表制作。资源还单独整理了诗人数据表能关联分析作者生平、作品风格及创作背景方便开展专题研究。目前已有2423人学习下载适合需要批量获取结构化诗词数据、构建古诗语料库、进行跨朝代对比分析或设计诗词教学活动的读者无论是学术研究、课堂实践还是个人兴趣都能从中快速找到可用素材是一款兼具实用性与研究价值的传统文化数据资源。1. 中华古诗词大全数据库一套靠谱的诗词数据方案到底该怎么搭做诗词类产品、古文学习工具或知识付费内容库时最头疼的不是前端展示而是「底下的数据能不能撑住」。网上能抓到的古诗词语料看着很多真落到库里就发现格式乱七八糟、作者重名、朝代缺失、正文里混着白话译文查一句“举头望明月”都能把注释和赏析一起捞出来。标题里这个“中华古诗词大全数据库”说白了就是要把分散在各类网页和开源语料里的诗词文本清洗成一套结构规范、能稳定查询、可扩展的本地数据库。我给的方案是用 SQLite 做承载把诗词、作者、朝代拆成规范化的关系表再靠全文检索解决诗词搜索的核心痛点。这个组合适合个人作品集、中小型 Web 应用、离线工具和教学系统数据量级在几万到十几万条诗词时性能完全够用零运维成本。全文我会把表结构设计、清洗导入流程、索引与查询参数、以及我踩过的几个坑完整拆开讲照着做就能在本地跑通一套能用的诗词数据库。2. 从语料到字段古诗词数据库的表结构设计与选型理由2.1 为什么选 SQLite 而不是 MySQL 或 PostgreSQL先把结论放在前面如果你的诗词库目标是「本地可用、单机部署、数据量十万条以内」SQLite 是性价比最高的选择。很多人一上来就上 MySQL结果为了装个数据库还得配服务、管账号、开端口折腾半天还没开始导数据。SQLite 是一个单文件数据库整个库就是一个.db文件备份就是复制文件迁移就是拷贝文件没有任何守护进程。另外一个现实问题是市面上的古诗词语料高质量开源版通常就是几个 JSON 或 SQL 文件数据量从几万到几十万条不等。这个量级对 SQLite 来说毫无压力。SQLite 的单文件特性还让「分发给别人用」变得非常简单——你做完一个诗词查询工具直接把.db文件连同程序一起发出去对方不需要安装任何数据库服务。什么时候才需要换 MySQL 或 PostgreSQL当你的应用变成多用户并发写入、需要精细化权限控制、要跑在分布式架构上时再考虑。古诗词数据是典型的读多写少场景而且写入基本集中在初始导入阶段后续只是增量更新SQLite 的并发限制在这个场景下完全不构成瓶颈。2.2 三张核心表和字段规范诗词、作者、朝代古诗词数据不能只塞一张大宽表否则查询和去重都会变成灾难。我一般拆成三张表poems存诗词正文和属性authors存作者信息dynasties存朝代数据。作者和朝代独立成表的好处是统计某个朝代的诗词总量、查某位作者的全部作品时不需要在诗词表里反复 LIKE 匹配。poems表的设计要重点考虑三个字段title、content、dynasty_id。title看起来简单实际坑很多——同一首诗在不同语料里标题可能带「其一」「其二」后缀也可能带「并序」清洗时要决定是保留还是剥离。content字段直接决定查询体验建议存纯正文把注释、赏析、白话译文全部剥离出去避免全文检索时把解释性文字也搜出来。dynasty_id用外键关联朝代表避免在诗词表里冗余存「唐」「宋」这样的字符串——冗余存储会让以后做朝代级统计时多一步转换。作者表authors最少要有name、dynasty_id、bio三个字段。这里有个容易翻车的细节同一个作者在不同语料里名字写法可能不一致比如「李白」有的地方写成「李太白」或者简繁体混用。导入时如果没做归一化处理统计「李白作品数」就会漏数据。我一般在authors表加一个name_normalized字段存去除空格、统一简繁后的规范化名字查询时优先匹配这个字段。建表语句如下CREATE TABLE dynasties ( id INTEGER PRIMARY KEY AUTOINCREMENT, name TEXT NOT NULL UNIQUE, start_year INTEGER, end_year INTEGER ); CREATE TABLE authors ( id INTEGER PRIMARY KEY AUTOINCREMENT, name TEXT NOT NULL, name_normalized TEXT NOT NULL, dynasty_id INTEGER, bio TEXT, FOREIGN KEY (dynasty_id) REFERENCES dynasties(id) ); CREATE TABLE poems ( id INTEGER PRIMARY KEY AUTOINCREMENT, title TEXT NOT NULL, author_id INTEGER NOT NULL, dynasty_id INTEGER NOT NULL, content TEXT NOT NULL, tags TEXT, source TEXT, created_at TEXT DEFAULT (datetime(now)), FOREIGN KEY (author_id) REFERENCES authors(id), FOREIGN KEY (dynasty_id) REFERENCES dynasties(id) ); CREATE INDEX idx_poems_author ON poems(author_id); CREATE INDEX idx_poems_dynasty ON poems(dynasty_id); CREATE INDEX idx_authors_name ON authors(name_normalized);这段建表逻辑里poems表的author_id和dynasty_id都建了索引因为按作者筛选和按朝代统计是最常见的两类查询路径。authors表的name_normalized索引则是为了加速作者合并和去重时的匹配。注意dynasties.name加了UNIQUE约束防止导入时重复插入「唐」「宋」这样的记录。2.3 标签字段用 JSON 存还是用关联表很多诗词数据其实带有题材和风格标签山水、边塞、送别、咏史、婉约、豪放。我第一次做的时候用的是关联表方案——poem_tags和tags两张表多对多关系。后来发现一个问题古诗词打标签本身不是精确科学同一首诗在不同语料里标签口径不一致而且做关联表意味着每次查询都要 JOIN写起来繁琐。我现在的做法是折中方案poems表留一个tags字段用 JSON 数组格式存标签。SQLite 从 3.38 版本开始支持json_each()函数可以比较方便地解析。这个方案在“我需要反查某个标签下有哪些诗”时确实不如关联表高效但古诗词数据量级小实际查询时用tags LIKE %边塞%已经能秒回没必要为一万分之一的查询场景引入两张表的复杂度。如果你预期未来要做精细的标签筛选比如「找出所有同时含山水和隐逸标签的诗」那就规规矩矩用关联表。大多数情况下单字段 JSON 配合 LIKE 查询已经足够还能减少导入时的数据处理量。3. 从原始语料到干净数据清洗流程与幂等导入脚本3.1 公开语料有哪些来源各有什么坑古诗词的开源语料在 GitHub 上能找到不少常见的格式有 JSON、SQL dump 和 CSV。JSON 格式的最方便通常是一个数组每个元素包含标题、作者、朝代、正文等字段。SQL dump 格式的可以直接导入但里面可能带着原作者的建表结构字段名和类型不一定符合你的设计。CSV 格式则经常遇到字段里嵌了换行符导致解析错位的问题。不管哪种来源原始语料几乎必然有以下几类问题一是正文里混着白话译文和注释有的语料甚至把「译文」「注释」直接跟在原文后面二是简繁体混用同一个数据库里「發」和「发」并存三是作者字段不一致有的带字号有的只写名四是朝代字段花式多样有写「唐」的有写「唐朝」的有写「盛唐」的。这些坑不处理干净后边查询时全部会翻车。我一般会先写一个审计脚本不急着导入而是把原始语料里的字段值做 DISTINCT 统计看看朝代字段到底有多少种写法作者字段有多少个疑似重复项。这一步能让你对语料质量有底而不是盲目地一把梭导入再后悔。3.2 写一个可重复执行的导入脚本幂等设计是关键导入脚本必须做幂等设计——同一份语料跑两遍结果不能翻倍。实现幂等最简单的方式是给poems表加一个source字段记录每条数据的来源标识比如原始 JSON 里的 ID 或标题加作者加正文第一句的哈希值。导入时先查这个标识是否存在存在就跳过不存在才插入。Python 是目前处理这类清洗任务最顺手的语言配合标准库里的sqlite3和json就能完成整个流程。导入脚本的核心逻辑是先读 JSON再逐条清洗最后批量写入。写入时用executemany而不是单条execute循环性能差距在一个数量级以上。import sqlite3 import json import hashlib DB_PATH poetry.db DATA_FILE poetry_raw.json def normalize_text(text: str) - str: 统一换行符、去首尾空白、全角转半角 text text.replace(\r\n, \n).replace(\r, \n) text text.strip() # 全角逗号转半角避免标点不统一 text text.replace(, ,).replace(。, .).replace(, !).replace(, ?) return text def make_poem_hash(title: str, author: str, first_line: str) - str: 生成稳定的去重标识 raw f{title}|{author}|{first_line} return hashlib.md5(raw.encode(utf-8)).hexdigest() def import_poems(data_list: list): conn sqlite3.connect(DB_PATH) conn.execute(PRAGMA journal_modeWAL) conn.execute(BEGIN) author_cache {} for item in data_list: title normalize_text(item.get(title, )) author normalize_text(item.get(author, )) dynasty normalize_text(item.get(dynasty, )) content normalize_text(item.get(content, )) if not title or not author or not content: continue # 作者去重命中缓存则复用 id author_normalized author.replace( , ) if author_normalized not in author_cache: cursor conn.execute( SELECT id FROM authors WHERE name_normalized ?, (author_normalized,) ) row cursor.fetchone() if row: author_cache[author_normalized] row[0] else: # 朝代先查再插 conn.execute( INSERT OR IGNORE INTO dynasties(name) VALUES (?), (dynasty,) ) dyn_id conn.execute( SELECT id FROM dynasties WHERE name ?, (dynasty,) ).fetchone()[0] cursor conn.execute( INSERT INTO authors(name, name_normalized, dynasty_id) VALUES (?, ?, ?), (author, author_normalized, dyn_id) ) author_cache[author_normalized] cursor.lastrowid author_id author_cache[author_normalized] dyn_id conn.execute( SELECT dynasty_id FROM authors WHERE id ?, (author_id,) ).fetchone()[0] # 去重同一标题 同一作者 同一正文第一句 视为重复 first_line content.split(\n)[0][:20] dedup_key make_poem_hash(title, author, first_line) exists conn.execute( SELECT 1 FROM poems WHERE source ?, (dedup_key,) ).fetchone() if exists: continue conn.execute( INSERT INTO poems(title, author_id, dynasty_id, content, source) VALUES (?, ?, ?, ?, ?), (title, author_id, dyn_id, content, dedup_key) ) conn.commit() conn.close()这段脚本有几个值得留意的参数和逻辑。PRAGMA journal_modeWAL开启预写日志模式导入期间其他进程还能读数据库避免写入时把查询也堵死。BEGIN手动开启事务配合executemany或循环内单条插入最终一次性commit——如果每条都自动提交几万条数据会慢到怀疑人生。author_cache是内存字典避免每条诗词都去查一次作者表这是导入性能的关键优化点。清洗函数normalize_text里做了全角转半角标点这是为了后续搜索时用户输入半角标点也能命中。实际语料里经常出现全角逗号句号如果不在导入时统一查询时就得做两套标点匹配麻烦且容易漏数据。3.3 清洗时的两个特殊处理异体字与作者合并异体字是古诗词数据里最隐蔽的坑。同一个字在古籍刻本和现代整理本里写法不同比如「閒」和「闲」、「裏」和「里」、「遊」和「游」。处理策略要分场景如果目标是做展示和搜索建议统一为现代简体否则用户搜「闲」搜不到「閒」的版本体验很差。我一般会维护一个异体字映射表在normalize_text里逐字替换。VARIANT_MAP { 閒: 闲, 裏: 里, 遊: 游, 峯: 峰, 埜: 野, 菴: 庵, 飮: 饮, 羣: 群, } def convert_variants(text: str) - str: for old, new in VARIANT_MAP.items(): text text.replace(old, new) return text注意这个映射表不能贪多只处理高频且有把握的字。有些异体字在不同语境下含义不同盲目替换会改错诗意。保守策略是先跑一遍语料统计出现频率最高的异体字只对出现次数多的做映射低频的宁可保留原字也不要乱替换。作者合并是另一个常规操作。同一个作者名语料里「王维」和「王右丞」并存不合并的话作者维度统计就会失真。常见做法是以「名」为基准把「字」「号」作为别名映射到同一个author_id。在导入脚本里我会维护一个ALIAS_MAP字典如{王右丞: 王维, 杜工部: 杜甫}在归一化作者名时先查别名表。4. 查询性能的核心武器FTS5 全文检索与索引调参4.1 为什么 LIKE %关键词% 不够用诗词查询有一个典型场景用户只记得一句诗里的一两个词想搜出完整诗作。如果用WHERE content LIKE %明月%SQLite 会做全表扫描——哪怕只有五万条数据每次搜索都要把整列内容过一遍。数据量小的时候感觉不明显但一旦你加了其他过滤条件比如同时按朝代筛选查询计划会变得很复杂响应时间可能从毫秒级退化到秒级。FTS5 是 SQLite 自带的全文检索扩展专门解决这类子串匹配问题。它通过倒排索引把每个词映射到包含它的文档列表查询时直接走索引不需要扫描全表。对古诗词场景来说FTS5 的收益非常明显五万条诗词的content字段LIKE 查询可能要几百毫秒FTS5 只需要几毫秒。需要注意 FTS5 索引是独立于原表的影子表不能直接在poems表上建索引要么用外部内容表的方式关联要么把诗词内容冗余一份到 FTS 表里。外部内容表方式更省空间且支持实时同步但配置复杂冗余方式简单粗暴导入时多写一步查询时直接查 FTS 表再 JOIN 回原表拿完整字段。4.2 外部内容表 FTS5 的建表与查询示例我推荐用外部内容表方案虽然建表时多几行代码但它避免了数据冗余导致的一致性问题。下面是完整的建表和同步流程-- 创建 FTS5 外部内容表content 字段映射到 poems.content CREATE VIRTUAL TABLE poems_fts USING fts5( title, content, contentpoems, content_rowidid, tokenizeunicode61 ); -- 导入数据后执行索引重建 INSERT INTO poems_fts(fts5_content, fts5_title, fts5_rowid) SELECT content, title, id FROM poems;注意tokenizeunicode61是 SQLite 默认的分词器它按 Unicode 字符边界做分词。对中文来说这个分词器不会把句子切分成词而是把每个汉字或连续汉字串当作一个 token。这意味着 FTS5 在中文场景下做的是「包含匹配」而不是「语义分词」用户搜「明月」能命中所有包含这两个字的诗这正好符合诗词搜索的需求——因为诗词里没有空格分词概念子串匹配才是正确的搜索语义。查询时用MATCH语法SELECT p.id, p.title, a.name AS author, p.content FROM poems_fts f JOIN poems p ON p.id f.rowid JOIN authors a ON a.id p.author_id WHERE f.content MATCH 明月 LIMIT 20;这里的MATCH 明月走倒排索引性能远优于LIKE %明月%。如果想做多个关键词的匹配可以用AND组合MATCH 明月 AND 故乡这样能精确过滤同时包含两个词的诗句。注意 FTS5 的AND是大写小写会按普通词处理。一个容易忽略的参数是content_rowid。外部内容表模式下FTS 表的rowid必须对应原表的主键id否则 JOIN 回原表时会关联错数据。建表时花了很长时间排查过这个问题现象是搜索结果里出现了张冠李戴的诗词内容最后发现是content_rowid没指明导致 FTS 表默认用了内部自增 rowid。4.3 索引调优该建哪些索引哪些别建索引不是越多越好每个索引都会拖慢写入速度并占用磁盘空间。在诗词数据库这个场景poems表我只会保留三个索引author_id、dynasty_id和source去重标识。title字段要不要建普通索引取决于你的查询模式——如果用户经常按精确标题搜索「静夜思」建索引有价值如果只是模糊搜走 FTS5 反而更快。authors表的name_normalized索引必须建这是作者维度统计和去重的关键路径。dynasties表数据量极小只有十几个朝代不需要额外索引。关于 FTS5 的detail参数有一个取舍默认detailfull存储全文内容支持snippet()高亮函数如果设置为detailnone索引体积会更小但无法使用高亮功能。对诗词展示场景高亮命中的词是刚需所以保持默认即可。如果磁盘空间极度敏感可以考虑detailcolumn这是存储和功能的折中方案。5. 数据库导入与查询的 5 个常见坑现象、原因、解决方案5.1 导入到一半报「database is locked」现象使用 Python 脚本导入几万条数据时跑到中途抛出sqlite3.OperationalError: database is locked程序中断。原因SQLite 在同一时刻只允许一个写事务。如果导入脚本开了事务但长时间不提交或者有其他进程比如一个没关掉的数据库浏览器占着写锁导入就会被阻塞。还有一种情况是脚本里某个连接没关闭事务一直没有结束。解决导入前先检查有没有其他程序打开了同一个.db文件关掉数据库管理工具。脚本里务必用BEGIN和commit包裹写入操作事务在try/finally中提交异常时rollback。另外开启PRAGMA journal_modeWAL也能显著降低锁冲突概率因为在 WAL 模式下读操作不会阻塞写操作。5.2 导入后中文乱码标题和正文全是「锟斤拷」现象从 JSON 导入后终端查询中文显示正常但通过某些客户端工具查看时出现乱码或者写入前用print调试就是乱码。原因编码不一致。JSON 文件可能是 UTF-8但 Python 脚本在 Windows 下默认读取编码可能是 GBK或者 JSON 文件本身带着 BOM 头读取时没正确处理。SQLite 内部统一存 UTF-8但读写两端编码不对就会出乱码。解决打开文件时强制指定编码。用open(DATA_FILE, encodingutf-8)读 JSON如果遇到 BOM 用utf-8-sig编码。导入前先用normalize_text打印前三条数据确认无误再跑全量。这个坑属于「导入完成才发现全错」的典型翻车现场所以我的习惯是永远先导入 20 条做抽样验证。5.3 搜索「静夜思」搜不到但库里明明有现象用 FTS5 的MATCH 静夜思查询结果为空用LIKE %静夜思%却能查到。原因FTS5 默认分词器unicode61对连续汉字串的处理方式可能导致长短词匹配不一致。特别是用户输入的关键词比索引里的 token 短或者包含标点符号时MATCH匹配规则比LIKE严格。解决如果你确认 FTS5 的匹配行为不适合当前数据一个务实方案是「FTS5 查候选 LIKE 复核」两步走。先用 FTS5 放宽条件查出候选集再用LIKE精确过滤。另一种办法是改用 trigram 分词器——SQLite 3.34 以上支持tokenizetrigram它按三个连续字符切分对中文子串匹配更友好但索引体积会变大。对古诗词场景我建议直接上trigram能省掉很多搜索匹配的玄学问题。5.4 同一个作者拆成了两条记录统计数量不对现象SELECT COUNT(*) FROM poems WHERE author_id1和WHERE author_id2查出来的诗其实是同一个作者的作品。原因导入时作者归一化做得不彻底。原始语料里「李白」和「李太白」被当成两个作者分别插入了authors表或者同一个名字一个带空格一个不带。解决如果要救已经导入的数据先查SELECT id, name, name_normalized FROM authors找出疑似重复项用UPDATE poems SET author_id 保留的id WHERE author_id 要合并的id做归属调整再删掉废弃作者记录。根治办法是导入前就用别名映射表和去空格逻辑统一作者名这篇文章第 3 节已经写了对应代码。5.5 数据库文件越来越大备份和迁移要传半天现象明明只导入了五万条诗词.db文件却有 1.2GB复制到别的机器要等好几分钟。原因FTS5 索引把整段content都存了一份而且 SQLite 的页空间回收不积极删除数据后文件大小不会自动缩小。外部内容表模式下 FTS 表仍然会存储原始内容等于诗词正文存了两份。解决两种策略。如果不需要频繁更新索引用INSERT INTO poems_fts(poems_fts) VALUES(rebuild)重建索引能压缩内部碎片。真正有效的办法是导出再导入干净数据VACUUM INTO poetry_compact.db把整个库压缩到一个新文件然后拿新文件替换旧的。VACUUM 会重新组织页空间效果立竿见影我遇到的情况是文件直接从 1.2GB 缩到 380MB。6. 进阶用法把诗词数据库做成带增量同步和向量检索的完整方案数据库做到能查只是第一步真正的价值在于能不能持续更新和应对更多样的查询需求。增量同步这块我一般会在poems表上加一个updated_at字段每次导入新语料时记录导入批次号用source字段做天然的去重标识。同步时只扫描比上次批次号更新的数据这样日常补充新诗不需要全量重导。备份策略上VACUUM INTO是 SQLite 最推荐的方式它能在数据库运行期间生成一致性快照特别适合诗词库这种读多写少的场景。向量检索是另一个值得探索的方向。把每首诗的全文用 embedding 模型转成向量存进专门的向量数据库就能实现「找诗意相近的诗」这种语义搜索而不是字面匹配。实际落地路径是用 Python 的sentence-transformers或国内开源的文本向量模型对poems.content做批量向量化向量存到独立的向量库日常查询时先向量检索出候选诗 ID再回 SQLite JOIN 拿完整数据。这种方式适合做诗词推荐、风格聚类这种传统 SQL 搞不定的功能。最后一个想分享的习惯是每次导入新数据后固定跑一遍完整性校验。简单做法是抽查当前库中「每个朝代的诗词数量」是否和源语料一致或者随机抽出 50 首诗词人工核对标题、作者、正文是否对得上。这些校验脚本不用写得多复杂但能防止静默脏数据越积越多。诗词数据本身是文化资产库里的错误会直接误导使用者我宁愿导入慢一点也要保证每一批数据都能追踪来源、随时能回退——希望这些经验能帮你在搭库时少走几段弯路。本文还有配套的精品资源点击获取