MySQL 8.0 InnoDB并行扫描仅对无索引全表扫描的大InnoDB表生效，需显式开启innodb_parallel_read_threads>0且用EXPLAIN FORMAT=TREE验证；MyISAM完全不支持并行查询，因其单线程、表级锁、无并行机制设计。
MySQL 8.0 的 InnoDB 并行查询和 MyISAM 根本不是同一类机制，直接比“快多少”没有意义——MyISAM 压根不支持并行扫描。
MyISAM 完全没有并行查询能力
MyISAM 是单线程、表级锁的引擎，它的全表扫描（SELECT * FROM t）永远只用一个线程顺序读取 .MYD 文件。即使你把 key_buffer_size 调得再大，它也只缓存索引，数据页仍依赖 OS 缓存，且无法拆分任务、无法多线程读物理页。MySQL 8.0 的并行扫描功能（innodb_parallel_read_threads）在 MyISAM 表上完全被忽略，EXPLAIN 里连“Parallel scan”提示都不会出现。
InnoDB 并行扫描只在极窄路径下生效
InnoDB 的并行扫描不是“所有大表查询都变快”，它只在满足全部条件时才触发：
- 表必须是 InnoDB，且无有效索引可用（
type: ALL）或走大范围索引扫描（type: range） - 查询不能含
LIMIT、GROUP BY、ORDER BY、子查询、窗口函数 -
innodb_parallel_read_threads > 0（默认为 0，必须显式设） - 实际扫描行数足够大（通常 > 数百万），且未被优化器判定为“太小无需并行”
- 不能走覆盖索引（
Extra: Using index），否则跳过物理页读，自然不触发并行
例如：SELECT * FROM orders WHERE created_at > '2025-01-01'（created_at 无索引）可能并行；而 SELECT COUNT(*) FROM orders 或 SELECT * FROM orders WHERE id = 123 一定不并行。
别拿 MyISAM 当参照系来评估并行收益
MyISAM 在现代 MySQL 中已基本退出生产场景：它不支持事务、崩溃后易丢数据、高并发下表锁直接卡死。所谓“MyISAM 查询快”的认知，大多来自旧版小数据量、纯读、低并发的测试环境，在真实业务中早已失效。InnoDB 的并行扫描也不是为“取代 MyISAM”而设计，而是为缓解大表无索引扫描的 I/O 瓶颈。如果你真在对比性能，应该做的是：
- 先确认查询是否真的走全表扫描（
EXPLAIN FORMAT=TREE看有没有Parallel scan） - 用
EXPLAIN ANALYZE观察parallel_workers和rows_examined_per_worker是否非空 - 对比开启
innodb_parallel_read_threads=4前后，Innodb_rows_read的增长速率是否显著加快 - 同时监控
Handler_read_rnd_next—— 并行下它应远低于单线程时的值
真正容易被忽略的是：并行只加速扫描阶段，后续的 JOIN、排序、聚合仍在主线程串行执行。如果瓶颈不在扫描本身（比如 CPU 卡在 JSON 解析或 GROUP BY 分组），开并行毫无作用。
