简介面向汉字信息化处理、姓名笔画测算与书法教学工具开发的简繁汉字笔画及Unicode数据库整合笔画数量、笔顺顺序、Unicode与GB编码等字段适合需要按字形特征检索、校核字符编码或构建字库应用的开发者、教师与研究者。压缩包为rar格式共1个文件主体是一份可在MySQL中使用的sql数据文件体积约304KB结构紧凑便于建表后开展查询统计与批量核对。已有980人学习下载具备一定的参考热度。其价值在于把简繁汉字的笔画数量、书写顺序及多套编码对照集中到结构化表中每条记录围绕单个汉字组织可支撑输入法词库整理、姓名与诗词笔画分析、书法教学示例筛选、文本清洗及编码兼容处理等场景也便于按需拓展字段并接入既有系统减少重复收集与人工校对成本。1. 从一个真实需求说起为什么非得有份汉字笔画库去年给一个面向小学生的识字类应用做后端需求里有一条「生字表按笔画从少到多排序同笔画按横竖撇捺折排」。听起来就是一个ORDER BY的事翻车的地方在于库里只有汉字本身和拼音笔画数一个字段都没有。当时第一反应是随手写张映射表结果一查才发现常用字加生僻字两万多个简繁还得分开对更麻烦的是同一个码位在不同字源下笔画数能差一画。后来把 Unicode 标准里的 Unihan 数据整出来落成一套 MySQL 表才有了这份简繁汉字笔画及 Unicode 数据库。它适合做识字教育、字帖排版、姓名笔画测算、中文排序、古籍繁简对照这类需要「字—笔画—部首—码位」四件套的场景一份 SQL 导进去就能查。2. 表结构拆解三张表怎么把两万多个汉字和简繁关系装进 MySQL拿到一份数据库类资源第一眼看的不该是数据有多少行而是表怎么设计。汉字笔画这件事看着简单真正落到表上会碰到三个绕不开的问题笔画数不是唯一的、部首和笔画是两套体系、简繁不是一对一。这套库的核心就是围绕这三点拆出来的三张表外加两张辅助表。2.1 主表 hanzi一个字一行把「笔画」拆成四个维度很多人理解的笔画库就是「字 笔画数」两列真用起来会立刻不够。做部首检字法要部首笔画做字帖排版要知道除部首外还剩几画做笔画序排序要知道首笔笔形。所以主表把笔画拆成了stroke_total总笔画、stroke_radical部首笔画、stroke_remain剩余笔画和first_stroke首笔笔形四个字段。CREATE TABLE hanzi ( id INT UNSIGNED NOT NULL AUTO_INCREMENT, ch CHAR(1) NOT NULL COMMENT 汉字本身utf8mb4 下占一个字符, code_point INT UNSIGNED NOT NULL COMMENT Unicode 码位十进制如 19968 U4E00, code_hex CHAR(8) NOT NULL COMMENT U4E00 形式排查数据时对着看, stroke_total TINYINT UNSIGNED NOT NULL COMMENT 总笔画数, radical_no SMALLINT UNSIGNED DEFAULT NULL COMMENT 214 部首序号1-214, radical_ch CHAR(1) DEFAULT NULL COMMENT 部首字如 水、木、口, stroke_radical TINYINT UNSIGNED DEFAULT NULL COMMENT 部首本身的笔画, stroke_remain TINYINT UNSIGNED DEFAULT NULL COMMENT 除部首外的笔画, first_stroke TINYINT UNSIGNED DEFAULT NULL COMMENT 首笔笔形1横 2竖 3撇 4点捺 5折, structure VARCHAR(8) DEFAULT NULL COMMENT 结构左右/上下/半包围/独体, pinyin VARCHAR(64) DEFAULT NULL COMMENT 多音用空格分隔如 chang zhang, is_trad TINYINT(1) NOT NULL DEFAULT 0 COMMENT 1 表示繁体字形, PRIMARY KEY (id), UNIQUE KEY uk_code_point (code_point), KEY idx_stroke (stroke_total, first_stroke), KEY idx_radical (radical_no, stroke_remain) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COLLATEutf8mb4_unicode_ci;几个字段值得单独说。code_point存十进制整数而不是字符串是为了能直接做区间扫描比如取出基本区所有字只需要一句BETWEEN 19968 AND 40959走索引非常快code_hex是冗余字段只为人眼对照 Unihan 原始文件方便别拿它做查询条件。radical_no用的是传统 214 部首序号不是笔画数这两者经常被新手搞混——部首「水」是第 85 号本身 4 画但「氵」这种偏旁形态在数据里仍然归到 85 号靠stroke_remain区分。first_stroke是为排序准备的光有总笔画数排出来同笔画内部是乱的加上首笔笔形才能得到接近字典的笔画序。主表的唯一索引压在code_point上一个码位只能有一行这保证了后续做简繁映射关联时不会因为重复行炸出笛卡尔积。两个普通索引分别服务「按笔画查字」和「按部首查字」两条最高频的路径。is_trad不是从 Unihan 直接读的它取决于这一行代表的是简体字形还是繁体字形通常靠码位落在哪张源表来判定导入时计算写入。pinyin字段留了 64 字符因为多音字真的能有好几个读音用空格分隔比存 JSON 或者另开一张读音表更省事代价是模糊匹配拼音前缀时要写LIKE zhang%而不是 zhang这一点在业务层要提前约定好。2.2 映射表 hanzi_variant简繁不是一对一别急着 JOIN简繁关系是最容易掉进去的坑。直觉上「一个简体对应一个繁体」实际上「发」对应「發」出发和「髮」头发「干」对应「乾」「幹」「干」三种情况。如果直接在主表上挂一个trad_code字段一对多的时候要么丢数据要么一个简体行复制出好几行主键直接冲突。正确的做法是单独一张关系表把方向、类型、是否首选都标出来。CREATE TABLE hanzi_variant ( id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT, src_code INT UNSIGNED NOT NULL COMMENT 源字码位, dst_code INT UNSIGNED NOT NULL COMMENT 目标字码位, rel_type TINYINT NOT NULL COMMENT 1简到繁 2繁到简 3异体字, preferred TINYINT(1) NOT NULL DEFAULT 1 COMMENT 同源多目标时是否为首选对应, PRIMARY KEY (id), UNIQUE KEY uk_pair (src_code, dst_code, rel_type), KEY idx_src (src_code, rel_type, preferred), KEY idx_dst (dst_code, rel_type) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COLLATEutf8mb4_unicode_ci;rel_type分方向存看起来有冗余简到繁和繁到简可以互推但实际业务里两个方向查的频率都很高双向都建索引比每次写UNION或者OR条件清晰得多。preferred这个字段是血泪经验做简繁转换时如果拿到「发」直接返回所有繁体候选前端展示会变成一串体验很差标记首选之后默认取preferred 1的那条需要精确对照的场景再放开全部候选。uk_pair这个唯一索引同时承担了两个作用防止导入时同一条关系重复写入以及在INSERT ... ON DUPLICATE KEY UPDATE场景下做幂等更新。Unihan 里kSimplifiedVariant和kTraditionalVariant两个字段各自可能带多个值一个码位对应多个目标码位是常态这里不做任何「取第一个」的截断全部落表把选择权留给查询层。还值得一提的是异体字。rel_type 3这一档收的是「為/爲」「裡/裏」这类没有简繁关系但字形不同的对很多业务用不上可一旦要做古籍对照或者字形检索没有这一档就得回头补数据。2.3 辅助表与字段选型为什么笔画字段只用 TINYINT除了两张主表这套库还有一张部首字典表hanzi_radical214 行存部首序号、部首字、部首笔画、部首码位和一张可选的笔顺表hanzi_stroke_order存逐笔笔形串如「一丨ノ丶」对应的数字编码。部首表看着是冗余因为主表里已经有radical_ch和stroke_radical了但做「按部首笔画分组列出所有部首」这类下拉框时从 214 行的小表查比SELECT DISTINCT扫两万多行主表快一个数量级而且能保证部首顺序稳定。字段类型的选择上有几个明确取舍。笔画相关字段全部用TINYINT UNSIGNED范围 0-255实际汉字最多也就 48 画左右绰绰有余如果用INT每个字段多占 3 字节两万多行乘以四五个字段索引体积会明显变大。radical_no用SMALLINT是因为要存到 214TINYINT UNSIGNED上限 255 其实也够但留点余量给未来扩展。ch用CHAR(1)而不是VARCHAR(1)定长在 utf8mb4 下占 4 字节两万多行也就多几十 KB换来的是行内读取不用解析长度前缀。提示CHAR(1)在 utf8mb4 字符集下能正确存下扩展区的四字节汉字但如果你的库还是utf8三字节扩展 B 区之后的字会直接插入失败或者变成问号建库那一步就必须定死字符集。索引的设计也不是拍脑袋。idx_stroke (stroke_total, first_stroke)这个组合索引的顺序不能反因为最高频的查询是「给定笔画范围取字」stroke_total放前面才能做范围扫描first_stroke放后面用于范围扫描后的排序虽然 MySQL 8.0 之后对范围条件后的第二列排序未必能完全用上索引但至少能减少回表后的排序量。idx_radical (radical_no, stroke_remain)同理部首是等值匹配放前面剩余笔画做范围或者排序。真正决定这套表好不好用的不是字段多全而是每条高频查询路径上都有对应的索引。导入之前先把你业务里要写的 SQL 列出来反过来核对索引比导完之后再ALTER TABLE加索引安全得多——两万多行的表加索引不慢但如果表上已经有业务在跑加索引的锁表时间就够你喝一壶了。3. 建库导入从 Unihan 原始文本到可查询的库表设计定下来之后就是落地。这一步的难点不在 SQL 写得多复杂而在数据源格式和字符集两件事上。Unihan 的原始文件是一堆制表符分隔的文本字段多、注释多、同一个字段还可能有多个值字符集这件事则贯穿建库、连接、导入三个阶段任何一环没对齐都会翻车。3.1 建库建表字符集从第一条语句就必须定死建库这一步就一个原则字符集和排序规则在CREATE DATABASE时写死不要依赖服务端默认值。很多线上 MySQL 实例的默认字符集仍然不是 utf8mb4靠默认值建出来的库后面全是坑。-- 字符集和排序规则显式声明不依赖服务端默认配置 CREATE DATABASE IF NOT EXISTS hanzi_db DEFAULT CHARACTER SET utf8mb4 DEFAULT COLLATE utf8mb4_unicode_ci; USE hanzi_db; -- 连接级别也要对齐否则客户端发过来的字在服务端就被截断了 SET NAMES utf8mb4 COLLATE utf8mb4_unicode_ci;utf8mb4_unicode_ci和utf8mb4_0900_ai_ci怎么选前者在 MySQL 5.7 和 8.0 上行为一致后者只有 8.0 才有排序规则更新但跨版本迁移会出问题。这套库的数据以码位和笔画为主几乎不做字符串比较选utf8mb4_unicode_ci最省心。SET NAMES utf8mb4这行看着多余实际上决定了后面LOAD DATA或者批量 INSERT 时字节流怎么解释。少了这一句客户端发的是 utf8mb4 字节服务端按 latin1 解释表里就会存进一堆乱码而且这种乱码是不可逆的——存进去的是错误解码后的字节再改字符集也救不回来。建表语句按第 2 章的结构逐条执行即可顺序上先建hanzi_radical没有外键依赖再建hanzi最后建hanzi_variant。外键我一般不加两万多行的表用应用层保证一致性更灵活导入时也不会因为约束顺序卡住。注意如果你的 MySQL 是 5.7 且innodb_large_prefix没开utf8mb4下带多个索引列的表可能建不出来报「Specified key was too long」。这种情况把innodb_large_prefixON且行格式设为DYNAMIC即可或者直接上 8.0。3.2 解析 Unihan 文本kTotalStrokes 那一列其实有两个值Unihan 的数据文件是纯文本每行三列码位、字段名、字段值用制表符分隔#开头是注释。真正要解析的字段就四个kTotalStrokes总笔画、kRSUnicode部首与剩余笔画、kMandarin普通话读音、kSimplifiedVariant/kTraditionalVariant简繁对应。坑在kTotalStrokes上。很多码位的值不是一个数而是两个比如1 2分别对应不同字源下的笔画统计。直接int()会抛异常取第一个又会丢掉繁体字形的笔画。import re # 逐行解析 Unihan 数据文件抽出四个关键字段 PATTERN re.compile(r^U\([0-9A-F]{4,6})\t(\w)\t(.)$) stroke_map {} # 码位 - 笔画数列表 radical_map {} # 码位 - (部首号, 剩余笔画) variant_map [] # (源码位, 目标码位, 关系类型) with open(Unihan_IRGSources.txt, encodingutf-8) as f: for line in f: if line.startswith(#) or not line.strip(): continue m PATTERN.match(line.rstrip(\n)) if not m: continue cp, field, value int(m.group(1), 16), m.group(2), m.group(3) if field kTotalStrokes: # 值可能是 1 或 1 2第一列对应简体字源第二列对应繁体字源 stroke_map[cp] [int(x) for x in value.split()] elif field kRSUnicode: # 格式如 85.3 或 9.0带撇号表示简化部首取数值部分 head, _, tail value.partition(.) radical_no int(head.replace(, )) radical_map[cp] (radical_no, int(tail))kRSUnicode那个撇号是另一个小坑9.0表示这个字用的是部首「人」的简化形态「亻」序号仍然是 9。解析时把撇号去掉取数字就行但如果要还原「这个字在字典里查哪个部首」撇号信息其实有用可以在主表里加个布尔列标记我一般嫌麻烦就没加。简繁字段在另一个文件Unihan_Variants.txt里格式是空格分隔的多个UXXXXwith open(Unihan_Variants.txt, encodingutf-8) as f: for line in f: if line.startswith(#) or not line.strip(): continue m PATTERN.match(line.rstrip(\n)) if not m: continue cp, field, value int(m.group(1), 16), m.group(2), m.group(3) if field kSimplifiedVariant: for token in value.split(): variant_map.append((cp, int(token[2:], 16), 2)) # 繁 - 简 elif field kTraditionalVariant: for token in value.split(): variant_map.append((cp, int(token[2:], 16), 1)) # 简 - 繁这里int(token[2:], 16)是把U53D1这种形式转成十进制[2:]去掉前缀。rel_type的取值方向要和表定义对齐1 是简到繁2 是繁到简别写反了写反的后果是转换结果全变成反向而且因为两边都能查到数据测试时不容易发现。解析完之后要做的第一件事不是入库是统计。打印一下len(stroke_map)、len(radical_map)、len(variant_map)和前一次解析的结果比。Unihan 每个版本都会调整数据某次更新后总量突然少了几百条多半是文件换行了或者字段名改了这时候入库就是往坑里跳。3.3 批量写入与校验导完必须跑的三条对账 SQL入库用executemany批量插别一条一条execute。两万多行单条插在本地可能几十秒远程库上就是几分钟起步。import pymysql conn pymysql.connect( host127.0.0.1, port3306, userroot, password***, databasehanzi_db, charsetutf8mb4, # 连接字符集必须显式指定 autocommitFalse ) cur conn.cursor() rows [] for cp, strokes in stroke_map.items(): radical_no, remain radical_map.get(cp, (None, None)) # 两个笔画值时第一个当简体用第二个当繁体用只有一个值时简繁同用 simple_stroke strokes[0] trad_stroke strokes[1] if len(strokes) 1 else strokes[0] rows.append(( chr(cp), cp, fU{cp:04X}, simple_stroke, radical_no, remain, 0, # is_trad 0简体行 )) if len(strokes) 1: rows.append(( chr(cp), cp, fU{cp:04X}, trad_stroke, radical_no, remain, 1, )) cur.executemany( INSERT INTO hanzi (ch, code_point, code_hex, stroke_total, radical_no, stroke_remain, is_trad) VALUES (%s,%s,%s,%s,%s,%s,%s) ON DUPLICATE KEY UPDATE stroke_total VALUES(stroke_total), rows ) conn.commit()上面这段是简化版真实脚本还要处理is_trad的判定不能简单按「有几个笔画值」来定和ch字段的填充。但核心思路是同一码位在简繁两套数据下可能需要两行但主表的唯一索引压在code_point上两行会冲突。所以要么把唯一索引改成(code_point, is_trad)联合唯一要么主表只存字形本身简繁的差异笔画放到映射表里。我这里用的是第二种主表的uk_code_point改成uk_char_trad (code_point, is_trad)一个码位最多两行简体行和繁体行分别记录各自的笔画数。这样is_trad就不只是个标记而是唯一键的一部分查询时必须带上否则会取到两行。导完必须跑三条对账-- 1. 总量核对和前一次解析的统计对齐 SELECT COUNT(*) AS total, SUM(is_trad) AS trad_rows FROM hanzi; -- 2. 笔画缺失检查0 画和 NULL 都是异常 SELECT COUNT(*) FROM hanzi WHERE stroke_total IS NULL OR stroke_total 0; -- 3. 笔画分布看有没有集中在某个值上的异常 SELECT stroke_total, COUNT(*) AS cnt FROM hanzi GROUP BY stroke_total ORDER BY stroke_total;第三条尤其重要。正常分布应该是中间高两头低5 到 12 画最密集如果发现所有字的笔画都是 1那多半是解析时字段位置错位了如果 20 画以上的字数量为零说明繁体字源那部分数据整段没导进来回头查解析日志。4. 查询实战按笔画、部首、码位的几条真实 SQL数据落库之后真正决定这套库好不好用的是查询层。业务里的需求翻来覆去就那么几类按笔画范围取字、按部首检字、简繁互转、码位区间统计。每一类都有一两个容易写错的细节。4.1 按总笔画取字表为什么 ORDER BY 只写 stroke_total 会乱最基础的查询是「给我 5 到 8 画的常用字」。SELECT ch, stroke_total, first_stroke, pinyin FROM hanzi WHERE is_trad 0 AND stroke_total BETWEEN 5 AND 8 ORDER BY stroke_total, first_stroke, code_point LIMIT 300;ORDER BY里三个字段一个都不能少。只写stroke_total同笔画内部的顺序由存储引擎决定两次查询结果可能不一样做字帖分页的时候会出现同一页重复或者漏字这种 bug 排查起来非常折磨人。加上first_stroke之后同笔画内按横竖撇捺折排再补一个code_point兜底保证绝对稳定。is_trad 0这个条件必须带上。主表的唯一键是(code_point, is_trad)一个码位可能有简繁两行不带这个条件取出来的字表会有重复字形。想按笔画数分组统计每档有多少字用一句聚合就够SELECT stroke_total, COUNT(*) AS cnt FROM hanzi WHERE is_trad 0 GROUP BY stroke_total HAVING cnt 10 ORDER BY stroke_total;HAVING cnt 10是过滤掉只有一两个生僻字的档位实际展示分布图的时候好看很多。这个查询走idx_stroke的松散索引扫描两万多行的表上基本是毫秒级。如果业务需要「同笔画按起笔顺序排且起笔相同的按第二笔排」那就得在表里加stroke_seq字段存完整笔顺编码排序改成ORDER BY stroke_total, stroke_seq。这套库的笔顺表是可选的没有的话首笔排序已经能满足绝大多数教育类场景。4.2 部首检字法radical_no stroke_remain 的组合查询部首查字是所有字典类应用的核心交互用户先选部首再选「除部首外几画」。对应的查询是SELECT h.ch, h.stroke_total, h.stroke_remain FROM hanzi h WHERE h.radical_no 85 -- 85 水部 AND h.stroke_remain 5 -- 除部首外 5 画合计 9 画 AND h.is_trad 0 ORDER BY h.first_stroke, h.code_point;这里有个新手常犯的错以为「氵」是独立部首去查radical_ch 氵。实际上传统的 214 部首体系里没有「氵」三点水归在「水」部下序号 85。同理「扌」归「手」部64「忄」归「心」部61「讠」归「言」部149。数据里radical_ch存的是正形部首「水」要按偏旁形态查得在应用层做一层映射或者额外建一张偏旁到部首的对照表。-- 偏旁形态到标准部首的映射表业务层查字前先转换 CREATE TABLE radical_alias ( alias_ch CHAR(1) NOT NULL COMMENT 偏旁形态如 氵 扌 忄, radical_no SMALLINT UNSIGNED NOT NULL COMMENT 对应的标准部首序号, PRIMARY KEY (alias_ch) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; INSERT INTO radical_alias VALUES (氵, 85), (扌, 64), (忄, 61), (讠, 149);有了这张小表用户点「氵」的时候先SELECT radical_no FROM radical_alias WHERE alias_ch 氵拿到 85再去主表查两步都是主键查询比在应用里硬编码 switch 好维护。idx_radical (radical_no, stroke_remain)这个索引就是为这条查询建的等值加等值走索引非常干脆。如果业务还要按总笔画排把stroke_total也加进索引末尾变成覆盖索引能省掉回表。4.3 简繁互查与码位区间扫描简繁转换的查询依赖hanzi_variant表。给一个简体字「发」码位 0x53D1要拿到所有繁体候选SELECT s.ch AS simp, d.ch AS trad, v.preferred FROM hanzi_variant v JOIN hanzi s ON s.code_point v.src_code AND s.is_trad 0 JOIN hanzi d ON d.code_point v.dst_code AND d.is_trad 1 WHERE v.rel_type 1 AND v.src_code 0x53D1 ORDER BY v.preferred DESC;MySQL 支持0x前缀的十六进制字面量直接写码位比在应用层拼十进制可读性好。结果会返回「發」和「髮」两条preferred 1的排在前面。业务上做默认转换取第一条做对照展示取全部。反向查询把rel_type改成 2、src_code换成目标码位即可。注意不要写成rel_type IN (1,2)然后不加方向条件那样两个方向的记录会混在一起一个繁体能查出自己。码位区间扫描主要用于数据统计和数据完整性核对-- 基本区汉字码位范围是 U4E00 到 U9FFF共 20992 个码位 SELECT SUM(code_point BETWEEN 0x4E00 AND 0x9FFF) AS basic, SUM(code_point BETWEEN 0x3400 AND 0x4DBF) AS ext_a, SUM(code_point 0x9FFF) AS beyond FROM hanzi;这个查询的结果能直接告诉你数据覆盖到哪一层。如果ext_a是 0说明扩展 A 区的字没收进来做生僻字场景就会缺字如果beyond是 0扩展 B 区之后的四字节字符全没有人名里那些生僻字基本都查不到。提示BETWEEN 0x4E00 AND 0x9FFF里的十六进制字面量在 MySQL 里是按整数比较的不需要转成字符串性能上等价于两个整数常量索引照常走。5. 避坑与排查导入乱码、笔画对不上、扩展区查不到这套库从下载到能稳定用起来中间有几个坑几乎是必经的。下面五条是我自己和身边同行都踩过的按「现象 → 原因 → 解决」写清楚遇到问题直接对号入座。5.1 导入后汉字全变成问号或乱码现象SQL 文件source进去之后SELECT ch FROM hanzi LIMIT 10返回一堆???或者锟斤拷之类的乱码LENGTH(ch)返回 1。原因三个环节里至少有一处字符集不是 utf8mb4。客户端连接没设、库的默认字符集是 latin1、或者 SQL 文件本身是 GBK 编码保存的。最隐蔽的是客户端连接这一层mysql命令行工具在部分系统上默认字符集跟着my.cnf走配置文件里写的是latin1就全乱。解决先把 SQL 文件用file -i确认编码然后连接串上强制指定charsetutf8mb4JDBC 是characterEncodingutf8注意写utf8而不是utf8mb4驱动会自动映射命令行先执行SET NAMES utf8mb4。已经存进乱码的数据救不回来必须清表重导。5.2 同一个字的笔画数比字典上多一画现象「黄」查出来 12 画字典上是 11 画「骨」查出来 10 画字典上 9 画。原因Unihan 的kTotalStrokes里带撇号或者分列的两个值对应不同字源地的字形标准不同字源的笔画统计规则不一样。如果你导入时直接取了第二个值或者把两个值相加就会系统性地多出几画。解决解析时明确取第一个值作为简体行笔画第二个值作为繁体行笔画并且两个值相同时只存一行。同时把kTotalStrokes原始值保留在一个stroke_raw字段里出现争议时能对回去查是哪个环节取的数。5.3 扩展区生僻字插入直接报错或存成问号现象导入一个人名里的生僻字INSERT报Incorrect string value或者不报错但存进去变成?。原因库或者表的字符集是utf8三字节扩展 B 区之后的汉字是四字节编码utf8装不下。utf8mb4才能覆盖完整码位空间。解决库、表、连接三处全改成utf8mb4。如果是已经建好的表ALTER TABLE hanzi CONVERT TO CHARACTER SET utf8mb4可以原地转但要在业务低峰期做两万多行的表转换几秒钟但如果表上还有更大的关联表时间会线性增长。5.4 简繁转换 JOIN 之后结果行数爆炸现象查一个简体字对应的繁体返回了十几行排除重复之后还是多出好几条不相干的结果。原因hanzi_variant表里src_code和dst_code方向混着存查询时只加了src_code条件没加rel_type简到繁和繁到简两个方向的记录全被捞出来了或者 JOIN 主表时忘了带is_trad条件一个码位两行主表记录导致结果翻倍。解决查询里rel_type和is_trad两个条件必须同时存在一个控方向一个控字形。另外可以用SELECT DISTINCT兜底但根本解法是把条件写全DISTINCT只是掩盖问题。5.5 按部首查字查不到「江」「河」这类字现象用户点「氵」偏旁查出来是空的但「江」「河」明明在库里。原因数据里部首字段存的是正形部首「水」85 号用户点的是偏旁形态「氵」两者字符串不相等WHERE radical_ch 氵自然一条都查不到。解决建一张偏旁到部首的映射表查询前先转换或者直接在应用层用常量映射。这个问题在字典类应用里几乎是必踩的提前把radical_alias表建好能省掉后面一次线上故障。6. 二次开发把笔画库接进业务系统的几种改法数据能查之后大部分人的下一步都是把它接进自己的系统。这里说三个我最常用的改造方向都是改动量不大但收益明显的。第一个是给业务表补笔画字段。不要每次查询都 JOIN 汉字库直接在业务表上加stroke_total、first_stroke两个冗余列写入时同步过来。代价是数据可能不一致收益是列表页排序完全走业务表自己的索引查询快一个数量级。同步逻辑我一般放在写入的 service 层而不是数据库触发器触发器出问题排查起来太黑匣子。-- 业务表补冗余字段列表页排序不再 JOIN ALTER TABLE word_item ADD COLUMN stroke_total TINYINT UNSIGNED DEFAULT NULL, ADD COLUMN first_stroke TINYINT UNSIGNED DEFAULT NULL, ADD KEY idx_sort (stroke_total, first_stroke);第二个是做一层转换接口把「简繁互转 首选标记 多候选」封装成一个服务方法业务层只调convert(text, direction)不直接写 SQL。这样后面换数据源或者加缓存都不用动业务代码。第三个是缓存。汉字库是典型的读多写少、数据量小、变更极少全量两万多行完全可以一次性加载到 Redis 或者本地 Caffeinekey 用码位value 存{ch, stroke_total, radical_no, ...}的序列化结构。我们线上这套做法之后按笔画范围查字从 8ms 降到 0.3msQPS 上来之后数据库压力基本归零。改造方式改动量适合场景注意事项业务表冗余笔画字段小列表页排序、筛选写入时同步定期对账封装转换服务中简繁转换、多候选参数校验要严空值要有默认全量缓存到 Redis小高频查询、C 端数据更新时整体刷新别做增量最后提一个验证习惯每次改完导入脚本或者表结构先跑一遍总量对账和笔画分布对账再看一眼随机抽的二十个常用字的笔画对不对。这套库的数据质量不上不下的时候最难受——大部分字是对的就几个字错业务方报过来你都不知道是数据问题还是查询问题。从那以后我每次动这份数据之前都强制走一遍「总量 → 缺失 → 分布 → 抽样」四步核对跑完心里才踏实。希望帮到你。本文还有配套的精品资源点击获取
