Navicat中CHAR长度不生效是因为未在“长度”栏手动输入数字，MySQL要求CHAR必须显式声明长度（如CHAR(10)），留空会导致退化为CHAR(1)；CHAR(n)指n个字符而非字节，UTF8MB4下1汉字占4字节；长度过大浪费内存并影响索引性能；改长度可能截断数据，须先查MAX(LENGTH())并确保n≥当前最大字符数。
Navicat 设计表时选 CHAR 类型后长度不生效？
navicat 里选了 char，但保存后字段实际变成 char(1) 或被自动截断，常见原因是没在「长度」栏手动输入数字——它不会默认继承你填的示例值或留空。mysql 要求 char 必须显式声明长度（如 char(10)），否则建表语句会报错或退化为 char(1)。
实操建议：
- 在 Navicat 表设计器中，选中字段 → 「数据类型」下拉选
CHAR→ 立即在右侧「长度」输入框里键入具体数字（比如10），不能留空也不能填字母 - 若数据库是 MySQL 8.0+，
CHAR存储时会用空格补齐到指定长度，检索时默认去除尾部空格（受SQL_MODE影响，如启用了STRICT_TRANS_TABLES会更严格） - 注意区分「字符数」和「字节数」：UTF8MB4 编码下，一个汉字占 4 字节，但
CHAR(10)指的是 10 个字符，不是 10 字节
CHAR(1) 和 CHAR(255) 在存储与性能上真有区别？
有，而且很实在。虽然都是定长，但长度直接影响每行的固定开销和内存排序缓冲区使用量。
关键点：
-
CHAR(255)的字段，即使只存'a'，MySQL 也会分配 255×4=1020 字节（UTF8MB4）用于该列；而CHAR(10)只占 40 字节 - 大量
CHAR(255)字段会快速撑满max_allowed_packet和临时表内存限制，导致GROUP BY或ORDER BY报Memory table is full - 索引效率受影响：联合索引中含长
CHAR字段时，B+ 树节点能存的键值变少，树高增加，查询变慢
什么时候必须用 CHAR 而不是 VARCHAR？
不是“想定长就用 CHAR”，而是只有满足特定场景才值得牺牲空间换确定性。
典型适用情况：
- 固定位数编码：身份证号（
CHAR(18)）、手机号（CHAR(11)，国内）、国家代码（CHAR(2)） - 枚举类短字符串：状态码（
CHAR(3)存'ACT','INA'）、性别（CHAR(1)存'M'/'F'） - 需要严格对齐的报表导出字段，且下游系统依赖固定列宽（如某些银行接口要求 CSV 每行严格等长）
反例：姓名、地址、描述文本——这些明显长度可变，用 CHAR 是浪费空间且无收益。
Navicat 里改已有字段为 CHAR 长度，会不会丢数据？
会，如果新长度小于当前最长值，MySQL 会直接截断，且不提示警告（除非开了严格模式）。
例如原字段是 VARCHAR(50)，存了 '北京市朝阳区建国路8号'（12 个汉字），你改成 CHAR(10)，保存后该值变成 '北京市朝阳'（10 字符），后两个字永久丢失。
安全做法：
- 先查最大长度：
SELECT MAX(LENGTH(column_name)) FROM table_name; - 确保新
CHAR(n)的n≥ 当前最大字符数（不是字节数） - 生产环境务必在低峰期操作，并提前备份整张表
真正容易被忽略的是：Navicat 表设计器里点「保存」时，它生成的是 ALTER TABLE ... MODIFY COLUMN 语句，这个动作在 MySQL 中是“重建列”，隐含风险比看起来高。
