MySQL 5.7 升级到 8.0 后 InnoDB
行为变化最明显
升级本身不会强制切换存储引擎，但默认行为、SQL 模式和元数据管理方式变了。
InnoDB仍是默认引擎，但 8.0 引入了原子 DDL、数据字典统一存储（不再依赖
.frm文件）、以及更严格的事务一致性检查。比如
ALTER TABLE在 5.7 是非原子的，可能留下损坏表；8.0 默认原子执行，失败则回滚整个操作——这对依赖旧版“半成功”逻辑的应用可能触发异常。 显式指定
ENGINE=InnoDB的建表语句在两版本间兼容，但若省略，8.0 会用新默认（仍是 InnoDB，但页大小、redo 日志格式等底层参数可能随配置变化）
MyISAM表在 8.0 仍可读，但不支持在线 DDL、全文索引功能受限，且无法被 MySQL Router 或 Group Replication 自动识别 升级前用
SELECT ENGINE, COUNT(*) FROM information_schema.TABLES WHERE TABLE_SCHEMA NOT IN ('mysql','information_schema','performance_schema','sys') GROUP BY ENGINE; 检查非 InnoDB 表占比
升级后 MyISAM
表能用，但不能当主力引擎用
MySQL 8.0 并未删除
MyISAM，但官方明确标记为“deprecated”，意味着后续大版本可能移除。它不支持事务、行级锁、外键，且崩溃恢复能力弱于
InnoDB。更关键的是：8.0 的优化器对
MyISAM统计信息更新机制有改动，
ANALYZE TABLE可能不及时刷新，导致执行计划劣化。 如果业务中有
MyISAM表且频繁写入，升级后可能出现锁表时间变长、
INSERT DELAYED报错（该语法已在 8.0 移除）
SHOW CREATE TABLE输出中若看到
ENGINE=MyISAM，建议优先迁移到
InnoDB，尤其涉及
JOIN或事务混合场景 迁移不是简单改
ALTER TABLE t ENGINE=InnoDB：需确认
ROW_FORMAT（如
COMPRESSED在某些 8.0 小版本有 bug）、
KEY_BLOCK_SIZE兼容性，以及是否启用了
innodb_file_per_table
ARCHIVE
和 MEMORY
在 8.0 中基本可用但限制更多
ARCHIVE引擎在 8.0 中保留，但仅支持
INSERT和
SELECT，不支持
UPDATE/
DELETE/ 索引（连主键都不行），且压缩算法未更新，大数据量下查询性能比 5.7 更差；
MEMORY引擎仍存在，但 8.0 默认禁用哈希索引（
HASH），只允许
BTREE，且表大小受
max_heap_table_size严格限制，超限会静默转存到磁盘（使用
temptable引擎），这可能引发意料之外的 I/O 和锁等待。
CREATE TABLE t (id INT) ENGINE=ARCHIVE;在 8.0 可执行，但后续
ALTER TABLE t ADD INDEX idx_id(id);会直接报错
ERROR 1031 (HY000): Table storage engine for 't' doesn't have this option
MEMORY表在 8.0 启动时不会自动重建，重启后数据全丢，且无法参与复制过滤规则（
replicate-ignore-table对其无效） 若用
MEMORY做缓存表，务必检查
SHOW VARIABLES LIKE 'temptable_max_ram';，避免因内存不足触发隐式落盘
升级前必须验证 information_schema
和 performance_schema
查询是否受影响
8.0 彻底重构了数据字典，
information_schema不再是“视图”，而是访问内置字典表的只读接口。这意味着部分老查询会变慢或返回空结果，例如：
SELECT * FROM information_schema.TABLES WHERE ENGINE='MyISAM'仍有效，但
SELECT * FROM information_schema.COLUMNS WHERE COLUMN_TYPE LIKE '%blob%'可能在 8.0 返回更少列（因内部类型映射变化）；
performance_schema新增大量 instrument，但旧监控脚本若硬编码了
events_statements_history_long的字段顺序，可能解析失败。 检查所有备份/巡检脚本中是否含
information_schema的
TABLE_COMMENT、
COLUMN_DEFAULT等字段，8.0 对空值和 NULL 的处理更严格
performance_schema表名在 8.0 有新增（如
replication_applier_status_by_coordinator），但旧版工具若做
SHOW TABLES LIKE 'replication%'可能漏掉关键表 不要依赖
information_schema的响应时间做 SLA 判断——8.0 下首次查询可能延迟突增，这是字典缓存加载所致，非真实性能问题
实际升级时最容易被忽略的，是那些没写进文档的“隐式依赖”：比如应用层假设
MyISAM表
REPAIR TABLE能秒级完成，或监控系统把
information_schema.TABLES.DATA_LENGTH当作真实磁盘占用——这些在 8.0 都可能失效。
