升级mysql后需先查information_schema定位myisam等弃用引擎表，再检查create table语法兼容性，验证外键与事务行为差异，测试alter engine安全性，并注意隐式行为变更。
查看当前表使用的存储引擎
升级 MySQL 后，首先要确认哪些表还在用已弃用或行为变更的引擎（比如 MyISAM 或旧版 ARCHIVE）。执行以下查询能快速定位：
SELECT table_schema, table_name, engine
FROM information_schema.tables
WHERE engine IN ('MyISAM', 'MEMORY', 'ARCHIVE', 'CSV')
AND table_schema NOT IN ('information_schema', 'performance_schema', 'mysql', 'sys');
注意：MyISAM 在 MySQL 8.4+ 已被标记为“deprecated”，部分功能（如全文索引语法、修复逻辑）可能受限；ARCHIVE 在 8.0.29+ 起默认禁用，需显式启用 archive_engine=ON 才能加载。
检查 CREATE TABLE 语句是否含不兼容语法
MySQL 8.0+ 对 CREATE TABLE 的解析更严格，尤其涉及存储引擎相关子句。常见问题包括：
-
ROW_FORMAT=COMPRESSED在InnoDB表中仍可用，但若innodb_file_format已移除（8.0+），该参数实际被忽略，且不会报错——容易误以为生效 -
KEY_BLOCK_SIZE在 8.0.29+ 被完全忽略，即使写在建表语句里也不起作用 - 使用
ENGINE=MyISAM+DELAY_KEY_WRITE=1时，升级后该选项会被静默丢弃，且无 warning
建议导出建表语句并逐条检查：
SHOW CREATE TABLE `your_table`\G
重点关注 ENGINE 后面是否带了已被废弃的属性，以及是否混用了跨引擎专属参数（例如给 InnoDB 加 PACK_KEYS=1）。
验证外键和事务行为是否一致
引擎切换或版本升级可能导致外键约束、事务隔离级别、自动提交等行为变化。特别是从 MyISAM 迁移到 InnoDB 时：
-
MyISAM不支持外键，升级后若直接改引擎为InnoDB，但未重新定义外键，原有逻辑会丢失约束保障 -
InnoDB默认autocommit=1，但某些老应用依赖MyISAM的“伪事务”（靠锁表模拟），升级后需检查业务代码是否显式控制BEGIN/COMMIT - MySQL 8.0.23+ 修改了
READ COMMITTED下的间隙锁行为，若业务依赖旧版加锁粒度，可能引发死锁或幻读差异
运行前可临时开启 innodb_print_all_deadlocks=ON，并在慢日志中搜索 Deadlock found 确认是否因引擎行为变化触发异常。
测试 ALTER TABLE ENGINE 转换是否安全
批量转换引擎最常踩的坑不是语法错误，而是隐式锁表和元数据锁等待。在生产环境执行前务必验证：
- 8.0.23+ 中
ALTER TABLE ... ENGINE=InnoDB默认使用ALGORITHM=INPLACE，但若原表含FULLTEXT索引（MyISAM特有），会强制退化为COPY模式，锁表时间剧增 - 对大表执行转换时，
innodb_online_alter_log_max_size设置过小会导致中途失败，错误信息为：ERROR 1878 (HY000): Failed to create a column index on table - 转换后务必检查
information_schema.INNODB_TABLES中space字段是否非零——为 0 表示表空间未正确加载，后续 DML 可能报Tablespace is missing
建议先在从库或测试实例上跑通完整流程，再用 pt-online-schema-change 替代直接 ALTER，避开主库锁表风险。
真正麻烦的不是引擎能不能切，而是那些没写进文档的隐式行为变更——比如 MyISAM 的 INSERT DELAYED 在 5.7 就已废弃，但很多存量 SQL 还留着，升级到 8.0 后直接报语法错误，而开发往往只查主错误日志，漏看从库的 SQL_THREAD_STOPPED 状态。
