MyISAM 在 MySQL 8.4 中已被系统级移除，默认禁用且 CREATE TABLE ... ENGINE=MyISAM 直接报错；因其无事务、表级锁、不支持 MVCC、索引数据分离等缺陷，加之 MySQL Server 层核心功能全依赖 InnoDB，故不可用。
MyISAM 在 MySQL 技术栈中已不是“被淘汰的选项”，而是被系统级移除的事实标准。MySQL 8.4 官方文档明确标注：MyISAM is deprecated as of MySQL 8.4 and will be removed in a future version；更关键的是，8.4 实例默认不加载 MyISAM 插件，执行 CREATE TABLE ... ENGINE=MyISAM 直接报错 ERROR 1286 (42000): Unknown storage engine 'MyISAM'——它连语法层面都失效了。
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
为什么 MyISAM 不再是“可选”，而是“不可用”
-
MyISAM缺乏事务日志机制，没有redo log和undo log，崩溃后无法自动恢复一致状态，只能依赖myisamchk手动修复，且可能丢失中间事务 - 所有写操作强制使用表级锁：
UPDATE t SET x=1 WHERE y=2会锁整张表，高并发下读写完全串行化，SHOW PROCESSLIST中大量Locked状态就是典型表现 - 不支持 MVCC，
SELECT COUNT(*)虽快（靠内存计数器），但该值在并发写入时不准；而真实业务中，COUNT往往需配合WHERE条件，此时MyISAM同样要扫描数据文件，优势消失 - 索引与数据分离（
.MYD+.MYI）导致物理偏移易错位，OPTIMIZE TABLE成为高频运维动作，而该操作本身又会引发长时间锁表 - MySQL Server 层自 5.5 起深度绑定
InnoDB：系统表（mysql.*）、数据字典、DDL 原子性、在线 DDL 支持等全部基于InnoDB实现，MyISAM已无法参与核心流程
InnoDB 的不可替代性体现在哪些硬约束上
-
innodb_flush_log_at_trx_commit=1是默认配置，保证提交即持久化，这是金融、订单、库存类系统的底线要求 - 行级锁 + 间隙锁（Gap Lock）组合支撑了可重复读（
REPEATABLE READ）隔离级别，避免幻读，而MyISAM连最基本的一致性读都无法提供 - 聚簇索引结构让主键查询、范围扫描、覆盖索引天然高效；二级索引也自带主键回表能力，无需额外维护物理地址映射
-
Buffer Pool+Change Buffer+Doublewrite Buffer形成完整缓存与写保护链路，既扛住随机写压力，又防止部分页写失败导致数据页损坏
迁移老项目时最容易被忽略的三个坑
-
ALTER TABLE ... ENGINE=InnoDB不是原子操作：大表会锁表较久，建议在低峰期执行，并提前确认innodb_file_per_table=ON，避免全库ibdata1膨胀 -
MyISAM全文索引（FULLTEXT）语法虽兼容，但InnoDB的实现逻辑不同，分词、停用词、布尔模式行为需重新验证，不能直接复用 - 某些监控脚本或备份工具硬编码了
.MYD/.MYI文件路径，切换引擎后会失效，必须检查mysqldump、Percona XtraBackup或自研备份逻辑是否适配.ibd文件结构
真正卡住技术团队的，从来不是“能不能换”，而是“换完有没有漏掉隐式依赖”。很多线上事故不是出在 InnoDB 本身，而是旧系统里那些没声明却默认依赖 MyISAM 行为的 SQL、脚本、中间件逻辑。
