mysql里一个中文汉字占多少字节数？

嘿嘿，说到MySQL的字符集问题，我还真是有一些经验。
我记得以前有一个项目，大量的中文内容存储在电子表格中。
经过检查，发现使用的是latin1 字符集。
我当时就傻眼了，因为latin1 根本不支持中文，结果就是中文数据全是乱码。

后来改为UTF8 字符集。
这次好像没有什么问题了。
一个汉字实际上是3 个字节。
但说实话，当时我不太明白为什么MySQL的utf8 是阉割版，而真正的UTF-8 应该是utf8 mb4 当我检查时发现它是正确的。
utf8 mb4 还可以支持3 字节的汉字。
关键是它可以处理更多的字符，包括表情符号。

我们来谈谈varchar(N)的定义。
这个N代表字符数，而不是字节数。
例如，UTF8 字符集中，varchar(2 00)理论上可以存储2 00个汉字，但实际占用的字节数为2 00×3 =6 00字节。
还值得注意的是，MySQL 的最大行大小默认为 6 5 ,5 3 5 字节，因此您不能无限地存储数据。

很久以前，我接手了一个项目。
表结构设计非常复杂，有很多varchar字段。
我当时并不关心角色的问题。
结果，数据一导入就超出了最大行大小。
这件事让我想起了。
以后设计表结构的时候，得结合字符集和业务需求来计算字段的字节占用。

对于混合内容场景，例如字段中可能包含字符和汉字，则应根据汉字的比例来估算字段的长度。
例如varchar(2 00)可能只支持1 00个汉字加1 00个字符。

一般情况下，建议使用utf8 mb4 字符集，因为它支持完整的Unicode。
在设计表结构时，要综合考虑字符集和业务需求，不要让字符集问题成为顾虑。
我自己没有运行过这个。
我记得数据是这样的，不过我建议你查一下。

解决MySQL输入中文问题的方法简介mysql不能输中文

说实话，我已经厌倦了 MySQL 中的中文输入。
仔细想想，可以看到支持UTF-8 ，但是实际使用的时候却不能正常工作。
字符乱码或无法保存。
然后，经过一些缓慢的思考，我意识到我需要逐步去做，而不是随意改变。

我有一个朋友正在做一个项目，正在Windows服务器上直接安装MySQL。
默认字符集是 latin1 结果，他连中文都打不了了。
想起那一幕，他每天面对‘怪物墙’，就发疯了。
然后我更改了配置文件并告诉它将character_set_server = utf8 行添加到my.cnf中。
重新启动服务后，一切正常。
但说实话：这需要操作和维护权限，普通开发人员可能需要寻找系统管理员。

有趣的是，一些旧系统不允许您更改底层配置，因此您必须使用客户端设置。
当我使用Navicat连接时，我发现当我按住Shift键并单击“连接”按钮时，会弹出一个选择字符集的选项。
选择 UTF-8 并照常连接。
这种方法特别适合临时测试，但需要配置持久化方案。

对于代码中的配置我有最深刻的经验。
我之前使用Java创建了一个新闻系统。
数据库里的中文标题是好的，但是从前台检索出来却是乱码。
经过长时间检查，我意识到我忘记将 useUnicode=true&characterEncoding=UTF-8 添加到连接字符串中。
我添加后，效果很好。
但是，请记住，您需要确保数据库和表字符集匹配。
迁移旧数据库时，表级字符集没有改变，导致部分数据乱码。

我在创建数据时也遇到过陷阱。
客户要求必须保留繁体中文字符。
我直接用了utf8 数据库，发现无法保存。
经过一番研究，似乎UTF8 可以存储多种语言，但是也有局限性。
必须先创建相应的字符集COLLATE。
当时不知道原因，但经过测试发现直接用CREATE DATABASE utf8 _database CHARACTER SET utf8 COLLATE utf8 _general_ci创建后存储繁体字是正常的。

我没有亲自运行过这方面的InnoDB引擎，但我听说默认的utf8 mb4 更安全，可以存储emojis之类的东西。
我记得的资料是MySQL 5 .5 版本在2 01 0年开始全面支持utf8 mb4 ，我当时测试了一下，发现1 个emoji字符占用4 个字节。

我明白了，解决中文输入问题需要结合场景。
对于新系统，直接更改配置是最简单的。
对于临时测试，请使用客户端设置。
对于较旧的系统，向代码添加参数是最灵活的。
最重要的是保证从客户端到数据库到表的字符集一致。