MySQL 8.0 的 COUNT(*) 并行需同时满足无WHERE、无GROUP BY、无ORDER BY、无LIMIT、普通InnoDB表且走聚簇索引扫描，仅设innodb_parallel_read_threads=4不保证生效；必须通过EXPLAIN ANALYZE确认"parallel_workers">1及performance_schema观察多线程执行。
为什么 SET innodb_parallel_read_threads=4 后 COUNT(*) 还是单线程？
因为 innodb_parallel_read_threads 只是必要条件，不是充分条件。MySQL 8.0 的并行扫描对 COUNT(*) 的支持有严格限制：它只在**无 WHERE 条件、无 GROUP BY、无 ORDER BY、无 LIMIT、且表为普通 InnoDB 表（非分区、非临时）** 的情况下，才可能触发并行主键扫描。
常见失效原因包括：
-
EXPLAIN FORMAT=TREE输出里没出现Parallel scan—— 这是唯一可信信号，EXPLAIN或EXPLAIN FORMAT=JSON完全不显示并行信息 - 表上有二级索引且优化器选择了它（比如
COUNT(*)走了小的二级索引），InnoDB 就不会启动并行——并行只支持主键或聚簇索引扫描，不支持二级索引 - 数据量太小（如低于百万行），优化器认为并行开销大于收益，直接跳过并行路径
- 事务隔离级别为
REPEATABLE READ且存在 gap lock，可能静默降级为单线程
如何确认 COUNT(*) 真正用了并行扫描？
不能只看参数值或普通 EXPLAIN。必须组合两种验证方式：
- 执行
EXPLAIN ANALYZE SELECT COUNT(*) FROM huge_table;，搜索输出中是否含"parallel_workers": N（N > 1）和"rows_examined_per_worker"字段；若各 worker 扫描行数接近总量 / N，说明并行已生效 - 查询同时执行：
SELECT THREAD_ID, PROCESSLIST_INFO FROM performance_schema.threads WHERE PROCESSLIST_INFO LIKE '%COUNT%'，观察是否出现多个query exec类型线程（非connect或sleep） - 对比开启前后
Innodb_rows_read增速：并行下该值应显著快于Handler_read_rnd_next，表明 I/O 被分摊
并行 COUNT(*) 的实际效果受哪些因素拖累？
即使并行扫描启动了，也不等于 COUNT 查询就变快了。瓶颈常转移到其他环节：
- 并行只发生在 InnoDB 存储引擎层的物理扫描阶段，执行器层的计数汇总仍是单线程串行归并，worker 越多，leader 线程归并压力越大
- 如果表主键很大（比如 UUID 主键），每页能存的记录数少，导致扫描页数暴增，并行带来的 I/O 分摊收益被抵消
- 当
innodb_buffer_pool_size远小于表大小时，并行线程会争抢 buffer pool，引发频繁刷脏和锁竞争，反而比单线程更慢 - 并发执行多个并行 COUNT 时，
innodb_parallel_read_threads是会话级参数，但底层线程池共享，容易互相挤占资源
生产环境该不该依赖并行 COUNT(*)？
慎用。MySQL 8.0 的并行 COUNT 是“窄通道”能力：它只在极少数干净场景下生效，且性能提升不稳定。实测中，300 万行以下基本无收益；5000 万行以上才可能看到 2–3 倍加速，但前提是主键紧凑、buffer pool 充足、无并发干扰。
真正可靠的方案仍是业务层控制：
- 用单独的计数器表 + 应用层维护（INSERT/DELETE 时同步增减）
- 对近似统计需求，改用
SHOW TABLE STATUS LIKE 'table_name'中的Rows字段（误差可达 40%，但毫秒返回） - 分区表可并行查各分区
COUNT(*)再求和，这个逻辑可控、可监控、不依赖引擎黑盒
并行扫描是个需要精确对齐条件的“开关”，不是自动油门。配错参数、看错执行计划、忽略 I/O 和内存瓶颈，都可能导致你开着并行，跑得比关着还慢。
