MySQL 8.0 是否仍支持 MyISAM 存储引擎？

Question

MySQL 8.0 是否仍支持 MyISAM 存储引擎？尽管 MySQL 8.0 保留了 MyISAM 引擎的代码，允许读取现有 MyISAM 表并执行基本操作，但官方已明确不再推荐使用，并在数据字典和原子 DDL 等核心改进中排除对其支持。这意味着 MyISAM 在功能演进和可靠性方面存在局限。特别是在高并发、需要事务或崩溃恢复的场景下，InnoDB 明显更优。因此，虽然 MyISAM 尚未被彻底移除，但新项目应避免使用，现有实例也建议逐步迁移到 InnoDB。未来版本可能完全弃用 MyISAM，开发者需提前规划。

Answer 1

一、MySQL 8.0 是否仍支持 MyISAM 存储引擎？

是的，MySQL 8.0 仍然保留了对 MyISAM 存储引擎的技术支持，但这种支持已从“推荐使用”转变为“仅兼容性保留”。这意味着用户依然可以读取和操作现有的 MyISAM 表，包括执行 SELECT、INSERT（在表未被锁定时）、UPDATE 和 DELETE 操作。然而，官方文档明确指出，MyISAM 不再是默认或推荐的存储引擎。

-- 查看当前服务器支持的存储引擎
SHOW ENGINES;

在返回结果中，MyISAM 的 Support 状态通常为 "YES"，但 Comment 字段会标注类似 “Deprecated, not encouraged” 的提示，表明其已被弃用。

二、MyISAM 在 MySQL 8.0 中的功能局限性分析

• 不参与数据字典（Data Dictionary）重构：MySQL 8.0 引入了全新的事务性数据字典，取代了旧版本中的 .frm 文件机制。该字典仅管理 InnoDB 表元数据，MyISAM 表信息仍依赖文件系统存储，导致其无法享受原子 DDL、崩溃安全等特性。
• 缺乏原子 DDL 支持：所有涉及 MyISAM 表的 DDL 操作（如 ALTER TABLE）不具备原子性，若中途失败可能导致元数据与物理文件状态不一致。
• 无事务支持：MyISAM 不支持 ACID 特性，无法回滚操作，在高并发写入场景下易出现数据损坏。
• 表级锁限制：MyISAM 使用表级锁而非行级锁，极大限制了并发性能，尤其在混合读写负载下表现不佳。
• 崩溃恢复能力弱：断电或异常关闭后，MyISAM 表常需手动运行 myisamchk 工具修复，而 InnoDB 借助 redo log 可实现自动恢复。

三、典型应用场景对比：MyISAM vs InnoDB

特性	MyISAM	InnoDB
事务支持	❌ 不支持	✅ 完整支持
外键约束	❌ 不支持	✅ 支持
行级锁	❌ 仅表级锁	✅ 支持
崩溃恢复	⚠️ 手动修复	✅ 自动恢复
全文索引（MySQL 8.0+）	✅ 支持	✅ 同样支持
数据字典集成	❌ 独立文件	✅ 集成于 InnoDB 表空间
压缩表支持	✅ 静态压缩	✅ 动态压缩 & 透明页压缩
并发表写性能	⛔ 极低	✅ 高并发优化
地理空间索引	✅ 支持	✅ 支持
未来兼容性	❌ 可能移除	✅ 持续演进

四、迁移建议与实施路径

对于仍在使用 MyISAM 的生产环境，强烈建议制定逐步迁移至 InnoDB 的计划。以下是典型的迁移流程：

1. 识别所有 MyISAM 表：
   

   SELECT table_schema, table_name 
   FROM information_schema.tables 
   WHERE engine = 'MyISAM' 
     AND table_schema NOT IN ('mysql', 'information_schema', 'performance_schema', 'sys');

2. 评估应用依赖：检查是否有代码依赖 MyISAM 的特定行为（如 AUTO_INCREMENT 锁机制差异）。
3. 测试迁移影响：在非生产环境中执行 ALTER TABLE ... ENGINE=InnoDB，并监控性能变化。
4. 处理特殊功能：如原表使用了延迟插入（DELAYED INSERT），需改写为异步处理逻辑。
5. 启用监控告警：部署针对临时表使用 MyISAM 的审计规则，防止新对象创建。
6. 设置自动化脚本定期扫描，确保无人新增 MyISAM 表。
7. 利用 Performance Schema 分析锁等待、I/O 模式，验证 InnoDB 优化效果。
8. 更新部署文档与开发规范，禁止新项目使用 MyISAM。
9. 考虑使用 pt-online-schema-change 工具减少大表转换期间的锁表时间。
10. 完成迁移后，可通过参数 --disabled-storage-engines=MyISAM 进一步加固系统。

五、未来趋势与架构演进视角

graph TD
    A[MySQL 5.7 及更早] -->|广泛使用| B(MyISAM)
    C[MySQL 8.0] -->|兼容保留| B
    C -->|核心改进绕过| B
    D[MySQL 8.4+] -->|可能完全移除| B
    C --> E[InnoDB 成为核心]
    E --> F[统一数据字典]
    E --> G[原子 DDL]
    E --> H[多版本元数据管理]
    E --> I[增强复制一致性]
    J[云原生部署] --> E
    K[HTAP 场景] --> E

从架构演进角度看，MySQL 正在向“以 InnoDB 为中心”的统一存储模型收敛。诸如 Clone Plugin、InnoDB ReplicaSet、持久化统计信息等功能均深度绑定 InnoDB。MyISAM 已沦为历史兼容层，其存在反而增加了维护复杂度与潜在风险。