查看当前表使用的存储引擎
升级 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/COMMITMySQL 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状态。
