升级 mysql 后需重点关注存储引擎兼容性与性能变化，首先通过 SHOW CREATE table和 information_schema 确认各表引擎类型，尤其检查是否使用 MyISAM 等非 InnoDB 引擎；自 5.5 起 InnoDB 为默认引擎，若依赖 MyISAM 特性（如表锁、无事务恢复）需评估影响并迁移关键表至 InnoDB；注意 InnoDB 在 5.6+ 已支持全文及空间索引，可替代多数 MyISAM 场景；同时处理已弃用引擎如 FEDERATED 需显式启用，MERGE、csv不推荐用于核心业务；配置方面确保 innodb_file_per_table 合理设置，避免空间浪费；还需关注新版本默认行为变更，如 InnoDB 主键策略调整、行格式由 COMPACT 变为 DYNAMIC、严格模式 启用导致非法数据插入失败等；最终应在测试环境比对执行计划、事务隔离与锁表现，确保代码与配置适配，遵循提前审计、逐步迁移、充分测试原则以保障平稳升级。
mysql升级后，存储引擎的差异可能导致兼容性问题或性能变化。关键在于识别变更、评估影响并调整配置与代码。以下是一些常见处理方式。
确认当前使用的存储引擎
升级前应明确 数据库 中各表使用的存储引擎类型。可通过以下命令查看：
- SHOW CREATE TABLE 表名； — 查看具体表的建表语句及引擎类型
- select TABLE_NAME, ENGINE FROM information_schema.TABLES WHERE TABLE_SCHEMA = ‘ 你的库名 ’; — 批量检查所有表的引擎
重点关注是否使用了已弃用或行为改变的引擎，如 MyISAM 在高版本中的限制增强，或 InnoDB 功能扩展带来的默认行为变化。
注意 InnoDB 成为默认引擎的变化
从 MySQL 5.5 开始，InnoDB 是默认存储引擎。若旧系统依赖 MyISAM 的特性（如全文索引早期版本、表级锁行为），需特别留意。
- 检查是否有使用 MyISAM 特性的 SQL（如外键缺失容忍、崩溃后无需恢复等）
- 将关键表迁移到 InnoDB：ALTER TABLE 表名 ENGINE=InnoDB;
- 确保 innodb_file_per_table 等参数合理配置，避免空间浪费
InnoDB 现在支持全文索引（5.6+）和空间索引，多数 MyISAM 用途可被替代。
处理已弃用或移除的引擎
某些版本会移除老旧引擎。例如：
- BLACKHOLE、ARCHIVE 仍保留，但部分功能受限
- FEDERATED 默认可能关闭，需显式启用 federated_engine=ON
- MERGE 和 CSV 通常保留，但建议避免用于核心业务
如果应用依赖已被弃用的引擎，应 重构 数据访问 逻辑，改用本地表 + 应用层聚合或其他替代方案。
验证配置与行为一致性
新版本可能更改存储引擎的默认行为。例如：
- InnoDB 的主键创建策略（自动添加隐式主键的行为减少）
- 行格式默认由 COMPACT 变为 DYNAMIC（尤其在 Barracuda 文件格式下）
- 严格模式开启后，不合法数据插入会被拒绝
建议在测试环境比对升级前后查询执行计划、事务隔离表现和锁等待情况。
基本上就这些。关键是提前审计、逐步迁移、充分测试。
