MySQL 8.x超大规模表：char(14)与varchar(14)性能对比咨询

基于你描述的MySQL 8.x场景（20亿行主表、40亿总数据量、300G内存、字段为双列主键+关联唯一标识），直接给出结论和底层逻辑：

核心结论：char(14) 修改速度更快 #

1. 固定长度char的修改逻辑更高效 #

从char(10)扩容到char(14)，本质是固定长度的行格式调整：

• 单字节字符集下（符合你“仅增10GB”的描述），每行仅增加4字节存储，InnoDB执行Online DDL时，行数据的写入是规整的连续IO，内存缓存可高效批量处理数据。
• 主键及关联索引的重建过程中，固定长度的键值结构更规整，索引页填充率稳定，减少碎片化带来的IO开销，重建速度比可变长度索引更快。

2. varchar(14) 的额外开销 #

从固定长度char(10)转成可变长度varchar(14)，会引入两个关键开销：

• 每个varchar值需要额外存储1字节长度前缀（长度≤255时），导致行长度从固定值变为可变值，InnoDB重建表时需处理不同长度的行，磁盘碎片化更严重，随机IO占比提升，整体耗时增加。
• 即使95%的数据仅8字符，可变长度的索引键会导致索引页填充率波动，重建索引时需要更多页拆分和合并操作，进一步拖慢速度。

额外实操建议 #

• 强制开启Online DDL避免锁表：执行修改时加上ALGORITHM=INPLACE, LOCK=NONE参数，例如：

  ALTER TABLE your_main_table MODIFY COLUMN your_column CHAR(14) NOT NULL, ALGORITHM=INPLACE, LOCK=NONE;
  

• 提前监控资源：300G内存足够缓存大部分热数据，但要留意磁盘IO带宽和CPU负载，避免修改过程中资源耗尽。
• 务必先做全量备份：40亿级数据修改风险较高，备份是底线保障。

内容的提问来源于stack exchange，提问作者merlin