MyISAM表在MySQL 8.0中仍可SELECT，但已被系统性边缘化：基础查询可行，但information_schema查询易引发高延迟，ANALYZE/REPAIR TABLE阻塞线程且成功率低，含FULLTEXT索引时MATCH AGAINST行为不兼容，系统表为MyISAM则启动报MY-010929失败，ALTER TABLE ENGINE=InnoDB强制COPY算法并全表锁，唯一可靠转换方式是mysqld --upgrade=FORCE，禁用需配置disabled_storage_engines=MyISAM拦截建表。
能读，但不能当主力用——MySQL 8.0 中 MyISAM 表不是“挂了”，而是被系统性边缘化，任何依赖其旧有行为的场景都可能在升级后突然失效。
MyISAM 表在 8.0 中还能 SELECT 吗？
可以，基础查询不受限，但背后隐患极多：
- 每次
information_schema查询（比如SELECT * FROM information_schema.TABLES WHERE ENGINE='MyISAM'）都可能触发隐式OPEN TABLE，高并发下延迟飙升 -
ANALYZE TABLE和REPAIR TABLE会阻塞整个连接线程，且REPAIR TABLE在 8.0+ 中成功率极低 - 若表含
FULLTEXT索引，InnoDB 的分词逻辑与 MyISAM 不同，MATCH AGAINST可能查不到结果，这不是 SQL 写错，是索引行为变了 - 系统表（如
mysql.user）若仍是 MyISAM，mysqld启动直接报MY-010929并终止，连服务都起不来
为什么 ALTER TABLE t ENGINE=InnoDB 在 8.0 中特别危险？
这不是语法问题，而是执行模型根本改变：
- 该语句强制走
COPY算法，全程持有 MDL 写锁，所有读写请求全部阻塞 - 即使加了
LOCK=NONE，MySQL 也会自动降级为LOCK=EXCLUSIVE，因为引擎切换不支持无锁 - 大表（>10GB）执行中易触发磁盘满、超时中断、主从延迟跳到数小时
-
SHOW PROCESSLIST显示状态为copy to tmp table，不是“准备中”，是真的在全量拷贝数据
系统表仍是 MyISAM 会怎样？
这是阻断性错误，不是警告：
-
mysqld启动失败，日志明确报MY-010929 Storage engine 'MyISAM' does not support system tables -
mysql_upgrade已废弃（8.0.16+），执行它只输出mysql_upgrade is deprecated，对系统表零作用 - 唯一可靠方式是用
mysqld --user=mysql --datadir=/var/lib/mysql --upgrade=FORCE强制触发转换 - 失败常见原因：SELinux 权限未重置、残留
/var/lib/mysql/mysql/*.frm文件干扰、tmpdir或datadir空间不足
能否彻底禁用 MyISAM 避免误用？
可以，而且推荐——disabled_storage_engines = MyISAM 是 MySQL 5.7.8+ 提供的硬拦截机制：
- 配置后，
CREATE TABLE t ENGINE=MyISAM、ALTER TABLE t ENGINE=MyISAM、CREATE TEMPORARY TABLE ... ENGINE=MyISAM全部立即报错ERROR 3161 -
SHOW ENGINES里 MyISAM 仍显示YES，这是界面残留；真正判断是否生效，看建表是否报错 - 注意：某些老监控脚本或备份工具（如旧版
mysqldump）可能硬编码ENGINE='MyISAM'，需同步清理 - 禁用后，
CREATE TEMPORARY TABLE若未指定ENGINE，默认变成 InnoDB，事务行为差异可能导致中间状态不一致，必须回归验证
真正难排查的，是那些没报错但行为异常的情况：比如系统表部分转成功、部分失败，服务看似启动，但执行 CREATE USER 或权限变更时随机失败；或者从库上 MyISAM 表复制中断后静默错乱，REPAIR TABLE 无法恢复一致性。这些都不是配置调优能解决的，而是架构层面已不可靠。
