企业官网建设流程全解析

简介：这份MySQL数据库将简繁汉字的笔画数、笔顺、Unicode编码与GB编码整合为结构化数据，面向汉字输入法开发、汉字教学、书法研究以及姓名或诗词笔画计算等场景。资源包仅304KB，共1个SQL脚本文件，导入MySQL后即可生成汉字笔画信息表，支持按笔画数、笔顺等字段进行查询、排序与统计分析，例如快速筛选笔画最多的字或按书写顺序排列。已有980人学习下载。使用者无需自行爬取或整理汉字属性，可直接获得标准编码与书写顺序数据，便于快速搭建原型、开展字形对照研究，也可用于课程示例与演示，帮助学生理解笔画规则。无论是构建教学课件、输入法词库，还是开展字形统计，这些字段都能直接复用，省去重复整理工作。整体来看，该数据库体积小巧但字段完整，能有效缩短汉字类应用的前期数据准备周期，适合作为汉字信息化项目的基础数据集。

1. 汉字笔画及Unicode数据库（简繁）MySQL：这套数据到底解决什么问题

做识字类App、校对系统或者排版引擎的人，大概率都遇到过这三件事：一个字明明认识，但就是不确定它几画；一个简体字对应的繁体字在数据库里查不到；Unicode码点拿到了，却不知道怎么和笔画数一起存进MySQL。汉字笔画及Unicode数据库（简繁）MySQL，简单说就是把每一个汉字的码点、笔画数、简繁属性、Unicode类别整理成可查询的表，让排序、筛选和程序对接都有标准答案。它解决的是「汉字数据进MySQL之后怎么查、怎么排、怎么不丢字」的问题，适合正在做字库工具、输入法词库、中文教学软件，以及被字符集折腾过的人。这个方案不是要你从零造字库，而是把已经存在的公开数据整理成自己能维护的MySQL库。

2. 先拆分数据模型：笔画、码点、简繁为什么要分开建表

2.1 不要迷信「一个汉字一行」：三个现实反例

很多人第一反应是建一张表，字段叫「汉字、笔画数、Unicode码、简繁标识」，然后往里灌数据。这种设计自己写几个查询没问题，一旦碰上真实中文文本，立刻会发现三个反例。

第一个反例是同一个汉字有多个码点。「里」和「裡」是简繁关系，但「里」本身在Unicode里还有一个兼容汉字符号；「户」和「戶」更典型，简体和繁体在Unicode中是不同的码点，可字形几乎一样。如果你用汉字本身做主键，这一行插进去另一行就撞了。第二个反例是笔画数和码点没有因果关系。Unicode是按部首和笔画排序编码的，但「一」的码点小于「丁」，「丁」的码点小于「七」，码点顺序和笔画数排序并不完全一致，只存一个字段根本没法做稳定的笔画排序。第三个反例是简繁不是一对一。「干」的繁体可能是「幹」也可能是「乾」，一个简体字对应多个繁体字是常态，如果表结构里只放一个「繁体」字段，数据必然丢。

所以我的结论是：不要试图用一张宽表解决所有问题。应该把「字符本身」「笔画明细」「简繁映射」「Unicode类别」拆开，用码点作为稳定关联键。这样后续加数据源、加笔顺、加异体字都不用改主表。

2.2 码点当主键，汉字只当业务属性

为什么不直接拿汉字做主键？因为汉字是给人和业务看的，码点是给计算机看的。一个程序从外部拿到一段文本，要查笔画，最可靠的做法是拿到字符后调用ord()得到整数码点，然后用这个整数去查MySQL，而不是把字符拼进SQL字符串里等数据库去解析。字符在传输过程中受客户端字符集影响，可能被转成错误字节；码点是整数，不会因为连接字符集变化而改变。

我一般会把码点字段设计成INT UNSIGNED，同时保留一个CHAR(6)的十六进制形式，类似U+4E2D，方便人读和调试。汉字本身用VARCHAR(4)就够，因为Unicode里汉字在基本平面最多占4个字节（utf8mb4），但码点可能落到扩展区，那个字符用VARCHAR(4)存没问题，只是排序和比较仍然依赖码点字段。主键用码点，业务键用「汉字+变体类型」的组合唯一索引，这样同一个字形出现在不同分区时也不会互相覆盖。

简繁映射单独建一张表，不塞进字符主表。原因很简单：一个简体字可能映射到多个繁体字，一对多关系在关系型数据库里就该用子表表达。映射表里再加一个map_type字段，标记是「一一对应」还是「一简多繁」，以后做全文检索或者词向量对齐时，就知道该按哪种规则展开。

2.3 建表SQL：utf8mb4、InnoDB、外键与索引怎么选

建库建表这一步是后面所有操作的地基。先上完整SQL，我标注了每一处的选择理由。

-- 建库：必须用utf8mb4，而不是utf8 CREATE DATABASE hanzi_unicode DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; USE hanzi_unicode; -- 字符主表：一个码点一行 CREATE TABLE char_base ( cp INT UNSIGNED NOT NULL COMMENT 'Unicode码点（十进制）', hex_cp CHAR(6) NOT NULL COMMENT 'U+XXXX十六进制表示', char_text VARCHAR(4) NOT NULL COMMENT '汉字字符', unicode_category CHAR(2) NOT NULL DEFAULT 'Lo' COMMENT 'Unicode类别，如Lo=汉字，Po=标点', stroke_count TINYINT UNSIGNED NOT NULL COMMENT '总笔画数', variant_type ENUM('简','繁','异体','通用') NOT NULL DEFAULT '通用' COMMENT '简繁属性', source VARCHAR(32) DEFAULT NULL COMMENT '数据来源标识', PRIMARY KEY (cp), UNIQUE KEY uk_char_variant (char_text, variant_type) ) ENGINE=InnoDB COMMENT='汉字码点与笔画基础表'; -- 笔画明细表：一个字多笔，一对多 CREATE TABLE char_strokes ( cp INT UNSIGNED NOT NULL COMMENT '关联char_base.cp', stroke_seq TINYINT UNSIGNED NOT NULL COMMENT '第几笔，从1开始', stroke_name VARCHAR(8) DEFAULT NULL COMMENT '笔形名称，如横、竖、撇', PRIMARY KEY (cp, stroke_seq), CONSTRAINT fk_strokes_cp FOREIGN KEY (cp) REFERENCES char_base (cp) ) ENGINE=InnoDB COMMENT='汉字笔顺明细表'; -- 简繁映射表：一对多关系显式表达 CREATE TABLE char_simp_trad_map ( simp_cp INT UNSIGNED NOT NULL COMMENT '简体码点', trad_cp INT UNSIGNED NOT NULL COMMENT '繁体码点', map_type ENUM('一一对应','一简多繁','繁简共用') NOT NULL DEFAULT '一一对应', PRIMARY KEY (simp_cp, trad_cp), CONSTRAINT fk_map_simp FOREIGN KEY (simp_cp) REFERENCES char_base (cp), CONSTRAINT fk_map_trad FOREIGN KEY (trad_cp) REFERENCES char_base (cp) ) ENGINE=InnoDB COMMENT='简繁一对一/一对多映射表';

这段SQL里有几个参数值得单独说明。数据库字符集用utf8mb4而不是utf8，是因为MySQL里的utf8最多只支持3字节，扩展B区以外的汉字会变成问号，utf8mb4才覆盖完整Unicode。排序规则我选utf8mb4_unicode_ci，它基于Unicode Collation Algorithm，比general_ci更接近字符语义，虽然性能略慢，但汉字库的写入是一次性的，查询性能远没到瓶颈。cp字段用INT UNSIGNED，最大能存42亿，Unicode目前码点总量约110万，完全够用。hex_cp用CHAR(6)，因为U+10FFFF刚好6位，如果后面想存小于0xFFFF的码点，也不会有空字符串问题。外键这里不是摆设，char_strokes和char_simp_trad_map都依赖char_base，加上外键后删除主表数据时如果关联数据没清干净，会直接报错，这反而是好事，免得你误删了字库还在那儿查半天。

有人会问为什么不给unicode_category建索引。我的建议是建一个普通的B+树索引，因为后续判断标点符号时会按这个字段过滤。ALTER TABLE char_base ADD INDEX idx_unicode_category (unicode_category); 这一句可以放在导入数据之后再执行，避免导入时索引频繁更新拖慢速度。

3. 数据灌入MySQL：从源文件到可查询表的完整操作

3.1 先归一化源数据：CSV、JSON、UnicodeData.txt都转成同一种行格式

建完表就要面对现实：手上拿到的数据往往不是为MySQL准备的。常见源有三种。第一种是公开的汉字笔画表，通常是CSV，列名类似「汉字,总笔画数,备注」，但简繁体混在一起。第二种是Unicode联盟发布的UnicodeData.txt，里面有码点、字符名、Unicode类别，但它只涵盖字符属性，不管笔画数。第三种是语言处理工具生成的JSON，比如某个字库项目导出的记录，包含简体、繁体、笔顺、笔画数等。

我自己的习惯是先写一个小脚本，把不同来源全部转成统一的CSV行，格式固定为cp,hex_cp,char_text,unicode_category,stroke_count,variant_type,source。这一步看着简单，实际上是最容易翻车的地方。比如CSV里汉字列可能带着BOM头，第一行第一个字会变成类似「国」前面加零宽空格；再比如逗号分隔时字符本身可能包含英文逗号，必须用引号包裹。下面这段Python脚本可以完成原始CSV到目标格式的转换：

import csv import sys # 输入文件比如 raw_hanzi.csv，列：汉字,总笔画数,简繁标签 # 输出文件 target.csv，列顺序符合char_base表 input_path = "raw_hanzi.csv" output_path = "target.csv" with open(input_path, encoding="utf-8-sig") as rf, \ open(output_path, "w", encoding="utf-8", newline="") as wf: reader = csv.reader(rf) writer = csv.writer(wf) writer.writerow(["cp", "hex_cp", "char_text", "unicode_category", "stroke_count", "variant_type", "source"]) for row in reader: if not row or len(row) < 3: continue char_text = row[0].strip() if not char_text: continue try: stroke_count = int(row[1]) except ValueError: stroke_count = 0 variant_type = row[2].strip() if len(row) > 2 and row[2].strip() else "通用" cp = ord(char_text) hex_cp = f"U+{cp:04X}" unicode_category = "Lo" # 先用默认值，后续用UnicodeData.txt补全 writer.writerow([cp, hex_cp, char_text, unicode_category, stroke_count, variant_type, "raw_csv"])

这里用utf-8-sig读源文件，能自动去掉BOM；用ord(char_text)拿到十进制码点，再用格式化成U+加四位十六进制。unicode_category先统一填Lo，这个不严谨，等导入后再用UnicodeData.txt批量更新。source字段记录数据来源，方便以后追溯哪些字是从哪份文件来的，真出问题不至于对着黑匣子猜。

3.2 LOAD DATA INFILE导入：参数、权限、失败重试

归一化后的CSV可以直接用LOAD DATA导入，比一条一条INSERT快几个数量级。我实测过五万字左右的数据，逐条INSERT要几分钟，LOAD DATA基本秒级。下面是导入脚本：

mysql --local-infile=1 -u root -p hanzi_unicode -- 在MySQL客户端里执行 LOAD DATA LOCAL INFILE '/path/to/target.csv' INTO TABLE char_base CHARACTER SET utf8mb4 FIELDS TERMINATED BY ',' OPTIONALLY ENCLOSED BY '"' LINES TERMINATED BY '\n' IGNORE 1 LINES (cp, hex_cp, char_text, unicode_category, stroke_count, variant_type, source);

关键参数是LOCAL INFILE，它让客户端把文件内容传给服务器。如果报错提示LOCAL INFILE被禁止，需要先检查两个地方：启动MySQL时有没有加--local-infile=1，以及全局变量local_infile是不是ON。执行SET GLOBAL local_infile = ON;可以打开，但只对之后的新连接生效。CHARACTER SET utf8mb4必须写，否则客户端会把文件内容按系统默认字符集解析，极可能把汉字读成乱码。OPTIONALLY ENCLOSED BY '"'是告诉解析器，字段可以被双引号包着，但不强制，这样即使字符里有逗号，只要在引号内就不会被错误拆列。

这条语句执行完，建议立即做一次校验：SELECT COUNT(*), COUNT(DISTINCT cp) FROM char_base;如果两个数不一致，说明有重复码点被忽略或者部分行导入失败。LOAD DATA遇到主键冲突默认是报错中断，所以导入前最好先把目标表TRUNCATE，保证是干净导入。如果要允许重复行覆盖，可以在LOAD DATA后面加REPLACE关键字，但我更倾向于先导入临时表，再通过INSERT SELECT去重，这样原始数据不会因为一次误操作就被破坏。

3.3 简繁映射与Unicode类别的补全：不要手动拼

简繁映射和Unicode类别这两块数据，最重要的原则是别手动维护。手动维护几百个字没问题，一上规模就必然出错。正统做法是借助公开的简繁对照表和Unicode官方文件，通过代码自动补齐。

Unicode类别可以用官方UnicodeData.txt补全。这个文件的每一行以分号分隔，第一个字段是十六进制码点，第三个字段是类别。解析脚本如下：

# 解析UnicodeData.txt，更新char_base.unicode_category import mysql.connector category_map = {} with open("UnicodeData.txt", encoding="utf-8") as f: for line in f: parts = line.strip().split(";") if len(parts) >= 3: cp = int(parts[0], 16) category = parts[2] category_map[cp] = category cnx = mysql.connector.connect( host="127.0.0.1", user="root", password="your_password", database="hanzi_unicode", charset="utf8mb4" ) cursor = cnx.cursor() for cp, category in category_map.items(): cursor.execute( "UPDATE char_base SET unicode_category = %s WHERE cp = %s", (category, cp) ) cnx.commit() cursor.close() cnx.close()

这个脚本的逻辑很直白：把官方文件解析成字典，再一条条更新。五万个字的UPDATE可能在本地跑几十秒，可以接受。将来如果不想逐条更新，也可以用临时表先INSERT脱机文件内容，再JOIN更新，但那是性能优化，现阶段不用着急。

简繁映射我用类似的思路。写法上不外乎读一个简化字到繁体字的映射JSON，然后往char_simp_trad_map插入。重点是map_type字段要区分一对一和一对多。判断方法很简单：同一个simp_cp如果对应两个trad_cp，那它就是「一简多繁」。但你不要只看一次数据，因为简繁映射有普遍规则和异体字差异，某些字在GBK和Big5体系里对照关系并不一致。我的建议是保留source字段，把「来自标准简化字总表」和「来自民间字库」分开记录，查询时优先取官方映射。这个库如果将来要用于搜索索引，一对多的映射会直接影响召回率，所以绝不能拍脑袋合并。

4. 查询与应用层接法：笔画排序、标点判断、程序集成

4.1 按笔画数排序：为什么ORDER BY stroke_count和ORDER BY char_text不一样

很多人以为查到汉字表后，ORDER BY char_text就能按笔画排，这是中文搜索里最常见的错误认知之一。MySQL的字符集排序规则基于Unicode码点，而码点排序是「先按部首，再按笔画」的康熙字典序，不是纯笔画数顺序。如果业务要的是「一画字在前、二画字在后」这种纯笔画排序，唯一可靠的做法就是ORDER BY stroke_count。

-- 按笔画数从少到多，同笔画内按码点排序保持稳定 SELECT char_text, stroke_count, hex_cp FROM char_base WHERE variant_type IN ('简', '繁') ORDER BY stroke_count ASC, cp ASC;

这个查询的稳定点在最后那个cp ASC。同笔画数的字很多，如果不加二级排序，每次查询返回顺序可能因为执行计划变化而不同，导致前端页面翻页时看到字的位置跳来跳去。加上cp后就固定了。但要注意，同笔画数内按码点排，不是按部首排序，所以如果你要做「字典检索式」的笔画排序，光有笔画数不够，还需要携带部首或笔顺特征字段。

真正要满足出版级的笔画序，表里必须加一个sort_key字段，例如把每个字的笔画序列转成「横=1、竖=2、撇=3、点=4、折=5」的编码字符串。排序时按这个编码逐位比较。这个字段在导入阶段就要生成，写完字库再回头补会十分痛苦。如果你还没这笔数据，最稳妥的做法是先按stroke_count排，至少能满足大多数识字场景。

4.2 基于Unicode类别判断中英文标点：一个可复用的SQL

标题里的Unicode数据库不只是存汉字，还要能用于判断标点。判断中英文标点这个需求，热搜词里也经常出现。关键在于Unicode类别字段只能告诉你它是不是标点，不能告诉你它是中文标点还是英文标点。比如中文逗号U+FF0C的类别是Po，英文逗号U+002C的类别也是Po，单看category字段两者完全一样。

要通过MySQL判断，得把码点范围也考虑进去。中英文标点区分主要在两个Unicode区块：CJK符号和标点区块（0x3000-0x303F）以及全角形式区块（0xFF00-0xFFEF）。中文常用标点基本都落在这两个区块内。可用下面这条SQL：

-- 判断一个字符是否是中文标点 SELECT char_text, hex_cp, unicode_category, CASE WHEN cp BETWEEN 0x3000 AND 0x303F THEN '中文标点' WHEN cp BETWEEN 0xFF00 AND 0xFFEF THEN '中文标点（全角形式）' WHEN unicode_category LIKE 'P%' THEN '英文标点' ELSE '非标点' END AS punct_type FROM char_base WHERE char_text = '，' OR char_text = ',' OR char_text = '。';

这个CASE表达式的优先级很关键。先判断码点范围，再判断Unicode类别，这样全角逗号会被归为中文标点，半角逗号落入LIKE 'P%'分支被归为英文标点。实际项目里，你可以把这段查询包成一个视图或者存储函数，应用层只需要传一个字进去，就能拿到标点类型。注意0xFF00到0xFFEF区间里并不全是标点，它包含全角字母、全角数字，但如果你已经限定unicode_category LIKE 'P%'，那么全角字母不会误入标点阵营。

4.3 程序集成：GBK转Unicode后再查MySQL的最小链路

很多Windows上位机和老系统还在用GBK编码文本。LabVIEW里把GBK转成Unicode是常见操作，热搜词里也频繁出现。核心思路是：GBK字节流先进内存，按GBK解码得到字符，再用ord()拿到Unicode码点，最后用码点查MySQL。这样可以避开数据库连接字符集和源文件编码的互相干扰。

下面是一个最小可用的Python集成示例，逻辑同样适用于其他语言：

import mysql.connector # 模拟从LabVIEW或文件中拿到的GBK字节流 gbk_bytes = b'V4C0' # 这是"国"的GBK编码 char_text = gbk_bytes.decode('gbk') cp = ord(char_text) cnx = mysql.connector.connect( host="127.0.0.1", database="hanzi_unicode", user="root", password="your_password", charset="utf8mb4" ) cursor = cnx.cursor(dictionary=True) cursor.execute( "SELECT char_text, stroke_count, hex_cp, unicode_category " "FROM char_base WHERE cp = %s", (cp,) ) row = cursor.fetchone() cursor.close() cnx.close() if row: print(row["char_text"], row["stroke_count"], row["hex_cp"]) else: print("未找到", char_text)

这里有两个容易被忽略的参数。第一个是mysql.connector.connect里的charset="utf8mb4"，它保证查询参数里的字符串以完整Unicode形式发送给服务器，如果漏了，GBK解码出来的字符在传输中可能被截断。第二个是SQL里用%s参数化占位，而不是把cp直接拼进字符串，这既避免SQL注入，也避免码点被当作字符串比较时触发隐式转换。顺序很重要：先把GBK字节decode成字符，再取码点，最后查库，不要直接把GBK字节丢进数据库，因为MySQL根本不知道那串字节是GBK还是别的编码。

5. 避坑：Unicode数据进MySQL后最常翻车的5个现场

5.1 查询结果全是问号：utf8与utf8mb4的坑

现象：导入时明明看到汉字正常，重新打开客户端查询，返回的却是「??」或者乱码。原因几乎都是连接字符集没对齐。MySQL的utf8实际是utf8mb3，最多存3字节，而很多扩展汉字需要4字节，一旦客户端和表字符集没有统一成utf8mb4，传输过程中字节就被替换成问号。解决：建库建表时显式指定utf8mb4，连接时也指定charset="utf8mb4"。老项目里如果已经用了utf8，赶紧执行ALTER TABLE char_base CONVERT TO CHARACTER SET utf8mb4，然后重启连接。还有一个隐蔽问题是某些客户端工具默认用latin1连接，即使表是utf8mb4也会乱码，需要在连接参数里写死SET NAMES utf8mb4。

5.2 排序结果永远不符合笔画：COLLATE帮不了你

现象：执行ORDER BY char_text LIMIT 20，出来的字完全不是从少画到多画。原因：MySQL排序规则是按码点或拼音，不是按笔画数。别指望COLLATE utf8mb4_unicode_ci能按笔画排，这不属于Unicode默认排序算法的范围。解决：不要用char_text排序，用stroke_count排序；需要出版级笔画序的，必须建笔顺编码字段。这里有个替换思路：如果你只是想让字按「常用字优先」排，那应该维护一个frequency字段，而不是在排序规则上折腾。

5.3 简繁映射手动维护：一简对多繁是常态

现象：查到「干」只映射到「幹」，结果用户搜「干」时没召回「乾」。原因：简繁并非一一对应，任何手工维护的简繁表都会漏。解决：在char_simp_trad_map里为同一个simp_cp允许插入多个trad_cp，map_type标记为「一简多繁」。查询时INNER JOIN映射表会得到多行，这就是预期行为。真正的坑在于很多现成映射数据默认只保留第一个映射，导入时要去重策略改成「保留全部」，否则后映射的行会因为主键冲突被跳过。

5.4 LOAD DATA导入到一半报错，idb文件膨胀

现象：LOAD DATA执行到中间遇到主键冲突或编码错误，事务回滚，但表空间文件已经变大，磁盘占用明显上涨。原因：InnoDB在导入时为保证一致性会写undo日志，中断后不立即回收空间。解决：导入前TRUNCATE表，导入时先建一个和最终表结构相同的临时表，导入成功后再INSERT SELECT到正式表。日常可以用OPTIMIZE TABLE回收空间，但不要在业务高峰期执行。如果你要用数据库同步工具把这份数据迁移到另一台机器，务必确认工具对VARCHAR(4)字段的字符集转换是UTF-8到UTF-8，很多同步软件默认假设源库是latin1，同步完汉字就变成问号。

5.5 判断中英文标点只查category翻车

现象：用unicode_category LIKE 'P%'判断标点，结果把中文句号、英文句号、中文逗号、英文逗号全混在一起。原因：Unicode类别只区分标点、字母、数字这种大类，不区分中英文。解决：按4.2的SQL，把码点范围判断放在前面。这里容易再踩一个小坑：全角逗号U+FF0C和中文顿号U+3001虽然都是中文标点，但不在同一个Unicode块，所以判断中文标点时要同时覆盖0x3000-0x303F和0xFF00-0xFFEF两个区间，而不是只写一个BETWEEN。

6. 把方案落地：验证数据完整性、扩展笔顺与封装视图

6.1 用官方码点表做交叉验证

数据灌完后，先做一次全量校验：把char_base里的码点和Unicode官方码点表比对，看有没有不存在的码点，有没有漏掉的常用汉字。常见做法是导出一份码点清单，然后用Python的set做差集。校验SQL很简单：

SELECT COUNT(*) AS total_chars, COUNT(DISTINCT hex_cp) AS unique_cps FROM char_base;

如果total_chars和unique_cps不一致，说明有码点重复，通常是同一字形出现在多个Unicode区块里。对于字库型项目，这种重复可以接受，但你应该在source字段里标注清楚，避免以后误以为数据脏。

6.2 扩展笔顺字段与按笔顺检索

如果现有数据只有笔画数，下一步最值得做的是补笔顺。在char_strokes表里已经有stroke_seq和stroke_name，你可以按笔画名称的首字母生成一个编码字段，比如「横=H、竖=S、撇=P、点=D、折=Z」。按笔顺检索时，把输入字转成编码序列，再用前缀匹配去查候选字。这个功能对书法教学和输入法开发很有用。

6.3 封装视图与存储过程后的日常使用

把4.2里的标点判断SQL封装成视图，把4.1里的笔画排序封装成存储过程，业务层就不用反复写复杂的CASE表达式。视图只读，适合给报表用；存储过程适合高频查询。我个人习惯是把基础表保持干净，所有业务逻辑都放视图和存储过程，这样换数据源时只需要改底层表，不碰应用。

6.4 落地的最后一句建议

这套数据库值不值得自己搭，要看你的核心需求是不是「持续维护汉字数据」。如果只是想要一张能查笔画数的表，买现成的数据文件更划算；但如果你要打通简繁、笔顺、Unicode类别这三者的关联，并让MySQL成为唯一数据源，那就按上面的表结构一步步做。自己动手的唯一后悔药是没在一开始就用码点做主键。我见过太多人用汉字当主键，最后被同一个字不同码点折磨到重来。先把地基打对，后面加字段、加数据都是顺手的事，希望帮到你。

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