升级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文件格式下）
- 严格模式开启后，不合法数据插入会被拒绝
建议在测试环境比对升级前后查询执行计划、事务隔离表现和锁等待情况。
基本上就这些。关键是提前审计、逐步迁移、充分测试。
