mysql 8.0未删除myisam但已弃用，innodb默认行为更严格（原子ddl、统一数据字典），myisam不支持事务/在线ddl/group replication，archive不支持索引，memory禁用哈希索引且易隐式落盘，information_schema和performance_schema查询需适配重构。
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 都可能失效。
