mysql 8.0中myisam已事实淘汰，系统表强制innodb，启用disabled_storage_engines=myisam时建表直接报错，且官方明确标记为deprecated；其所谓读性能优势在现代硬件与innodb优化下已不成立，而稳定性、事务、高可用支持全面缺失。
不用选，也不该选。 MySQL 8.0 中 MyISAM 已不是“性能权衡选项”，而是被官方标记为 deprecated、系统表全面弃用、高可用链路不兼容的遗留引擎。哪怕业务确实是读多写少，InnoDB 也已足够快，且代价远小于风险。
MyISAM 在 MySQL 8.0 中实际已不可用
MySQL 8.0 所有系统表（mysql.user、mysql.db 等）强制使用 InnoDB；若实例启用了 disabled_storage_engines=MyISAM（生产环境强烈建议），建表会直接报错 ERROR 3161 (HY000): Storage engine MyISAM is disabled。即使没禁用，SHOW ENGINES 输出中 MyISAM 的 Comment 字段明确写着 deprecated, not encouraged——这不是建议，是事实性淘汰信号。
- MySQL 8.0.33+ 版本的
mysql_upgrade和mysqlcheck --repair已跳过 MyISAM 表检查，修复成功率极低 - 主从复制启用
binlog_format=ROW（默认）时，MyISAM 会退化为STATEMENT模式，导致NOW()、UUID()等函数主从不一致 - 集群自动故障转移（如 InnoDB Cluster）检测到 MyISAM 表时，部分版本直接拒绝启动，报错
ER_UNKNOWN_STORAGE_ENGINE
所谓“读多写少 + MyISAM 更快”在 8.0 中基本不成立
MyISAM 的所谓优势集中在三处：COUNT(*)、全表扫描、索引体积小。但这些在 MySQL 8.0 + 现代硬件下早已被大幅削弱：
-
COUNT(*)：MyISAM 缓存行数，InnoDB 则走最小二级索引扫描（Handler_read_next指标可验证），大表差异通常在毫秒级，业务完全无感 - 全表扫描：InnoDB 聚簇索引天然局部性更好，配合
innodb_buffer_pool_size合理配置，实际吞吐未必低于 MyISAM - 索引体积：MyISAM 索引不存数据，但 InnoDB 的页压缩（
ROW_FORMAT=COMPRESSED）、透明页压缩（ZSTD）已能显著缩小空间差距
真正拉开差距的是稳定性：一次异常断电，MyISAM 表大概率报 Table is marked as crashed，而 InnoDB 依靠 redo log 自动前滚恢复，无需人工干预。
真要优化读多写少场景，该调 InnoDB，不是换引擎
读多写少不是选 MyISAM 的理由，而是调优 InnoDB 的线索。重点应放在：
- 把
innodb_buffer_pool_size设为物理内存的 70%~80%，确保热数据常驻内存 - 对高频
SELECT COUNT(*)场景，加冗余字段（如total_count），在事务中同步更新 - 用
SELECT ... FOR SHARE替代普通读，显式声明一致性语义，避免隐式锁升级 - 确认查询走索引：MyISAM 缺失索引时只是慢，InnoDB 缺失索引可能触发全表锁（
Innodb_row_lock_waits飙升）
别忽略 SHOW TABLE STATUS LIKE 'xxx' —— 它显示的是当前表真实引擎，不是建表语句里写的那个。很多旧库看似用 MyISAM，实则是 MySQL 5.7 升级时被静默降级或元数据损坏残留，早就不受支持了。
真正难处理的，从来不是“读多写少该不该用 MyISAM”，而是“这张表是否真的只读”：只要未来可能加个状态变更、关联更新、或接入支付回调，就必须现在就切 InnoDB。ALTER TABLE 切引擎在大表上可能锁表数分钟，且外键、全文索引等特性无法平滑迁移。
