MySQL 8.0彻底放弃MyISAM因其无法兼容ROW格式binlog，导致主从复制中断、数据错位、恢复失败；所谓性能优势在真实场景不成立，反增稳定性风险。
没有必要，而且风险远大于收益。 MyISAM 在只读报表系统中所谓的“性能优势”在现代 MySQL（尤其是 8.0+）和真实部署场景下基本不成立，反而会引入复制中断、数据错位、恢复失败等不可控问题。
MyISAM 在主从架构下根本无法稳定回放 ROW 格式 binlog
当前生产环境主库几乎全部使用 InnoDB + binlog_format=ROW。而 MyISAM 表无法正确解析和应用 ROW 格式的 binlog 事件：
- 复制线程常卡在
ERROR 1594 (HY000): Relay log read failure或ERROR 1032 (HY000): Can't find record in 'xxx' - 即使
SHOW SLAVE STATUS显示Seconds_Behind_Master = 0，部分 DML 可能已被跳过或静默失败 - 数据逻辑已偏移，但无任何告警——这类问题通常只在报表对账或下游依赖出错时才暴露
所谓“COUNT(*) 快”和“全表扫描快”在真实负载中并不存在
MyISAM 的 COUNT(*) 优势仅限于无 WHERE、无并发、无索引竞争的单表查询；而实际报表系统往往伴随 JOIN、GROUP BY、多连接池并发查询：
win可用的mysql指令skill
下载
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
- InnoDB 在
innodb_stats_method=sampled下对COUNT(*)做采样估算，比 MyISAM 全表扫描还快 - MyISAM 的表级锁在
ANALYZE TABLE、REPAIR TABLE或误执行INSERT DELAYED时会阻塞所有 SELECT - 实测：10 万行状态表在 TPS 500+ 场景下，MyISAM 从库 CPU 常飙至 95%，InnoDB 稳定在 60% 以下
“省内存”是伪命题，且代价是 IO 和稳定性
MyISAM 的 key_buffer_size 确实不缓存数据页，但它的 .MYD 文件必须频繁触发随机磁盘 IO：
- 对比调优后的
innodb_buffer_pool_size（设为物理内存 70%），InnoDB 缓存热数据页后 QPS 反超 MyISAM 20%~40% - MySQL 8.0+ 支持
ROW_FORMAT=COMPRESSED KEY_BLOCK_SIZE=8，压缩率可达 40%，且仍支持索引与事务一致性 - MyISAM 压缩表（
myisampack）是只读的，但无法防止未来某次 ETL 脚本漏判引擎类型导致误写——而 InnoDB 能靠事务回滚兜底
真正容易被忽略的一点：MyISAM 的“只读”不是系统保障的，只是人为假设。只要权限没锁死、脚本没校验、DBA 手抖一次 INSERT INTO ... SELECT，一致性就彻底破坏了。这不是性能取舍，是底线问题。
