mysql版本升级中的存储引擎差异与迁移方案

MySQL 8.0 升级后 InnoDB 表无法启动，因移除 Antelope 格式支持，需升级前将 FILE_FORMAT=Antelope 表转为 Barracuda；系统表空间表须导出导入；MEMORY 表数据必丢失，ARCHIVE 等第三方引擎不兼容，须逻辑迁移。

MySQL 5.7 升级到 8.0 后 InnoDB 表无法启动？检查 innodb_file_format 和 innodb_file_per_table

MySQL 8.0 彻底移除了对 Antelope 文件格式的支持，只保留 Barracuda。如果你的 5.7 实例中存在 ROW_FORMAT=COMPACT 或 REDUNDANT 且 FILE_FORMAT=Antelope 的表，在升级后可能报错 Tablespace is missing for table xxx 或直接拒绝加载。

实操建议：

• 升级前用

  SELECT TABLE_NAME, ROW_FORMAT, FILE_FORMAT FROM INFORMATION_SCHEMA.INNODB_SYS_TABLES WHERE NAME LIKE 'db_name/%';

  检查存量表格式
• 对 FILE_FORMAT=Antelope 的表，必须在 5.7 环境下执行 ALTER TABLE t1 ROW_FORMAT=DYNAMIC, ALGORITHM=INPLACE;（确保 innodb_file_per_table=ON）
• innodb_file_per_table 在 8.0 中默认为 ON，但若旧实例为 OFF，系统表空间（ibdata1）中的表无法被 8.0 正确识别 —— 必须先导出再导入

从 MyISAM 迁移到 InnoDB 时主键和全文索引行为不一致

MyISAM 允许无主键、支持全文索引无需额外配置；InnoDB 要求显式主键（否则隐式生成 6 字节 row_id），且全文索引需 innodb_ft_enable_stopword=ON 并重建索引才能生效。

实操建议：

• 迁移前用

  SHOW CREATE TABLE t1;

  检查是否缺失主键；若无，先加 ALTER TABLE t1 ADD id BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY FIRST;
• MyISAM 的 FULLTEXT 索引不能直接转换：需先 DROP INDEX ft_idx ON t1;，再 ALTER TABLE t1 ENGINE=InnoDB;，最后 ALTER TABLE t1 ADD FULLTEXT(ft_col);
• InnoDB 全文索引默认使用停用词表，搜索单字符（如 “a”、“I”）会失败 —— 可临时设 SET GLOBAL innodb_ft_enable_stopword=OFF;，但需配合 innodb_ft_server_stopword_table 自定义控制

MEMORY 表升级后数据丢失且无法持久化？别依赖它存关键状态

MEMORY 引擎在 MySQL 8.0 中未变更语义，但升级过程必然重启 mysqld，所有 MEMORY 表数据清空。更关键的是：8.0 默认启用 skip_log_bin 以外的二进制日志策略，而 MEMORY 表的 DML 不写 binlog，主从复制中不会同步，容易造成一致性幻觉。

实操建议：

• 禁止将 session token、计数器等有状态数据放在 MEMORY 表中；改用 InnoDB + 应用层 TTL 控制，或接入 Redis
• 若必须保留临时结构，改用 TEMPORARY TABLE（会话级，重启不影响），或在启动脚本中自动重建 MEMORY 表并预热基础数据
• 监控项要覆盖 Created_tmp_disk_tables 和 Created_tmp_tables，避免因 tmp_table_size 不足导致隐式落盘，性能陡降

ARCHIVE 和 COLUMNSTORE 等第三方引擎在 8.0 中不再兼容

MySQL 官方 8.0 不再打包 ARCHIVE 引擎（虽仍可编译启用），而 MariaDB 的 ColumnStore、Percona 的 TokuDB（已弃用）等完全不兼容 8.0 的数据字典重构。强行拷贝表文件会导致 Table 'xxx' doesn't exist 或崩溃。

实操建议：

• ARCHIVE 表必须导出为 SELECT ... INTO OUTFILE 或 mysqldump --tab，再用 LOAD DATA INFILE 导入目标库（目标表需先建为 InnoDB）
• 使用 information_schema.PLUGINS 确认当前可用引擎：

  SELECT PLUGIN_NAME, PLUGIN_STATUS FROM INFORMATION_SCHEMA.PLUGINS WHERE PLUGIN_TYPE='STORAGE ENGINE';

  ，若目标库无对应引擎，不要尝试 COPY 或 Symlink
• 涉及列存场景，优先评估 ClickHouse 或 MySQL 8.0 + JSON + Generated Columns + Functional Indexes 组合替代，而非强求引擎一致

最易被忽略的一点：MySQL 8.0 的数据字典完全内置于 INFORMATION_SCHEMA，所有表元信息不再依赖磁盘上的 .frm 文件。这意味着任何绕过 DDL 直接操作文件系统（如 cp / mv .ibd）的行为，在 8.0 中大概率失败 —— 迁移必须走逻辑导出或官方 mysql_upgrade（仅限 5.7→8.0 小版本）流程。