mysql 8.0 默认禁用并逐步移除myisam引擎，其表在运行时实际不可用，join变慢主因是引擎失效、统计信息缺失及优化器误判，应立即迁移至innodb并执行analyze table。
MySQL 8.0 **默认禁用 MyISAM 引擎**，且不再维护其优化路径——你看到的“联合查询变慢”，大概率不是查询本身变慢，而是表已被自动转换或降级为兼容模式，执行计划彻底失效。
MyISAM 表在 MySQL 8.0 中实际已不可用
MySQL 8.0.28 起完全移除 MyISAM 的系统表支持；8.0.33+ 版本中，mysqld 启动时若检测到 myisam_recover_options 或 key_buffer_size 非零，会直接报错退出。即使你手动保留了 .MYD/.MYI 文件：
- 服务器启动时会静默跳过 MyISAM 表注册，
SHOW TABLES可见但SELECT报错ERROR 1286 (42000): Unknown storage engine 'MyISAM' - 部分升级脚本（如
mysql_upgrade）会强制将 MyISAM 表转为 InnoDB，但未重建索引或统计信息，导致 JOIN 条件无法命中索引 - 旧版 MyISAM 的全表锁机制与 8.0 的并发控制层冲突，
EXPLAIN中type常显示为ALL，且rows值虚高数倍
如何确认你的“MyISAM 表”是否真的还是 MyISAM
别信 SHOW CREATE TABLE 的输出——它可能缓存旧定义。必须查运行时引擎：
SELECT table_name, engine FROM information_schema.tables WHERE table_schema = 'your_db' AND table_name = 'your_table';
如果返回 NULL 或 InnoDB，说明表已被转换。进一步验证：
- 执行
SELECT COUNT(*) FROM your_table，若卡住 >5 秒，基本可判定是转换后未ANALYZE TABLE，统计信息为 0，优化器误判为小表而选错连接顺序 - 检查错误日志：
grep -i "myisam" /var/log/mysql/error.log，常见提示如Storage engine 'MyISAM' does not support system tables - 运行
SHOW ENGINES;，确认MyISAM行的SUPPORT列是否为NO或DISABLED
MyISAM 关联查询变慢的真正瓶颈点
即使强行保留 MyISAM（如降级到 8.0.23 且关闭严格模式），以下三点会让 JOIN 明显劣化：
-
JOIN顺序被重排：8.0 优化器默认启用condition_fanout_filter=on，对 MyISAM 这类无行级统计的引擎过度预估扇出，常把大表提前驱动，引发海量临时行 - 没有真正的谓词下推：MyISAM 不支持
ICP（Index Condition Pushdown），WHERE 条件只能在 server 层过滤，Extra字段频繁出现Using where，且rows统计严重失真 - 元数据锁（MDL）争用加剧：MyISAM 表级锁 + 8.0 新增的 MDL 意向锁机制，在多线程 JOIN 场景下极易触发
Waiting for table metadata lock
绕过问题的实操路径
不要尝试“调优 MyISAM”，它在 8.0 中已属废弃路径。正确做法是快速收敛到 InnoDB：
- 用
CREATE TABLE new_table LIKE old_table; ALTER TABLE new_table ENGINE=InnoDB;复制结构，再INSERT INTO ... SELECT迁移数据（注意事务大小，避免撑爆 undo log） - 迁移后立刻执行
ANALYZE TABLE new_table;，否则优化器仍按 0 行估算 - 检查原 JOIN 条件字段是否都有索引：MyISAM 可能依赖全文索引或前缀索引，InnoDB 需要显式
INDEX，且复合索引须满足最左前缀 - 若原查询依赖 MyISAM 的
INSERT DELAYED或CONCURRENT INSERT特性，需改用应用层队列或INSERT ... ON DUPLICATE KEY UPDATE
真正棘手的不是语法或配置，而是 MyISAM 表一旦进入 8.0 环境，它的“存在”本身就是个幻觉——表面可查，底层已无完整执行语义支撑。任何试图在它上面做 JOIN 优化的动作，都是在和一个正在消失的引擎搏斗。
