MySQL 5.7三项数据库优化操作的最优执行顺序咨询

针对固定MySQL 5.7版本、Ubuntu部署的社区论坛场景，效率最高、风险最低的执行顺序为：存储引擎切换 → 行格式调整 → 字符集修改，具体判断逻辑和实操注意事项如下：

顺序判定的核心依据 #

• 第一步：将所有表的存储引擎从MyISAM切换为InnoDB
  这是所有后续操作的基础前提：
  • MyISAM和InnoDB的行格式是两套完全不兼容的规则，如果先给MyISAM表调整行格式，后续切InnoDB时会直接按InnoDB的默认配置重置行格式，前面的操作完全无效，平白多触发一次全表重建，论坛数据量通常几十到上百G，多一次重建可能多消耗数十分钟时间。
  • MyISAM不支持事务、没有崩溃恢复能力，后续改行格式、改字符集都是需要重写全表数据的重操作，如果在MyISAM状态下执行，中途出现掉电、磁盘打满、连接中断等问题，极高概率出现表损坏、数据丢失；切到InnoDB后再做后续操作，InnoDB自带的崩溃恢复机制可以自动修复异常中断的写入，大幅降低故障风险。
• 第二步：将所有InnoDB表的行格式调整为Dynamic
  • MySQL 5.7版本InnoDB的默认行格式是Compact，Dynamic是官方推荐适配大字段、多字节字符集的行格式：它对长文本字段采用全溢出页存储策略，比Compact行格式“存768字节前缀+挂溢出页”的方式IO效率更高，也能从根本上避免UTF8MB4字符下常见的索引长度超限报错。
  • 这一步放在字符集修改前，是因为行格式调整本身会触发全表重建，先把行结构调整到最终状态，后续改字符集时不需要重复触发表结构变更和重建。
• 第三步：将数据库字符编码设置为UTF8MB4
  • 字符集转换是三个操作里开销最大、耗时最长的步骤，需要逐行转换所有文本字段的存储编码，放在最后一步执行，只需要在已经是目标引擎、目标行格式的表上做一次全量转码即可，不会因为前面的引擎、行格式调整重复做转码操作，把全表重建的总次数压到最低。
  • 如果先在MyISAM+Compact行格式的基础上修改UTF8MB4，很容易碰到MyISAM单索引长度不超过1000字节的硬限制，直接导致SQL执行失败卡流程；在InnoDB+Dynamic行格式的基础上修改UTF8MB4，索引长度上限放宽到3072字节，基本不会碰到这类报错，执行顺畅度高很多。

实操前置提醒 #

• 所有操作执行前必须做全库物理备份，不要仅依赖mysqldump导出的逻辑备份，数据量大的时候物理备份的恢复速度快几个量级，出问题可以最快回滚。
• 操作阶段建议临时关站停写，不然表重建过程中新写入的帖子、用户信息很容易出现字符集乱码、表结构不一致的问题。
• 执行前检查MySQL配置文件中已经开启innodb_file_per_table=1，否则重建后的表会全部写入共享表空间，后续无法通过优化表回收碎片空间。
• 修改完库级别的UTF8MB4配置后，要同步转换已有表、已有文本类型字段的字符集为UTF8MB4，仅修改库级别字符集只对后续新建的表生效，老表不会自动调整。排序规则按需选择即可，追求排序准确性选utf8mb4_unicode_ci，追求极致性能选utf8mb4_general_ci。

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