MySQL 8.0 的并行查询不加速复杂事务处理，因其仅在只读、无锁、无 MVCC 干预的物理扫描阶段启用，而事务涉及行锁、MVCC、redo 日志等串行逻辑，优化器直接跳过并行路径。
MySQL 8.0 的并行查询特性**不加速复杂事务处理**，它根本不会在事务内启用——这是最关键的判断。
为什么事务里根本用不上并行查询？
MySQL 的并行扫描（Parallel scan）只发生在**只读、无锁、无 MVCC 干预**的物理扫描阶段。而事务处理（尤其是带 UPDATE、DELETE、SELECT ... FOR UPDATE 的事务）天然涉及：
- 行锁、间隙锁、临键锁，InnoDB 会主动禁用并行以保证隔离级别（特别是
REPEATABLE READ） - 事务日志写入（
redo log）、回滚段管理、MVCC 版本链遍历——这些全是串行协调逻辑 - 执行计划中若含
Using where; Using index condition或任何索引查找，优化器直接跳过并行路径
EXPLAIN FORMAT=TREE 看不到 Parallel scan 就等于没并行
哪怕你设了 innodb_parallel_read_threads = 8，只要执行计划第一行不是 -> Parallel scan on table_name，就说明并行完全没参与。常见失效场景包括：
- 事务中执行
SELECT COUNT(*) FROM t WHERE status = 1—— 即使status无索引，事务上下文也会强制退化为单线程扫描 - 语句带
FOR UPDATE或嵌套在存储过程事务块里，EXPLAIN甚至可能报错或不返回树形结构 - 使用
READ COMMITTED隔离级别时，部分版本仍因锁兼容性检查关闭并行（尤其在高并发更新场景下）
真正影响事务性能的，并行参数根本碰不到
事务瓶颈通常卡在以下环节，而这些环节和 innodb_parallel_read_threads 无关：
-
innodb_row_lock_waits和innodb_row_lock_time_avg高 → 行锁争抢，加并行线程只会加剧排队 - 大量
Handler_read_rnd→ 回表随机读，说明索引设计不合理，不是并行能救的 -
Innodb_buffer_pool_wait_free持续非零 → buffer pool 不足，页淘汰频繁，并行读反而加重 mutex 竞争 - 事务中混合 DML + 大范围 SELECT → 执行计划被拆成多个阶段，只有最外层全表扫描才可能并行，且仅限于该 SELECT 子句（如果存在且满足全部条件）
想提速复杂事务，别碰并行参数
把精力放在更实际的地方：
- 拆分长事务：把一个含 50 条
UPDATE和 1 次大表SELECT的事务，拆成小批量UPDATE+ 单独只读查询 - 确认
autocommit=1是否被意外关闭——隐式事务比显式事务更容易触发锁升级 - 用
performance_schema.events_statements_history_long查看事务内各语句耗时分布，定位真实慢点（常是某条UPDATE的索引未命中，而非扫描慢） - 对高频更新字段（如
status、updated_at）建覆盖索引，避免回表和锁扩大
并行查询不是事务加速器，它是针对特定只读扫描的窄带优化。试图在事务里“开启并行”就像给拖拉机装飞机引擎——结构不匹配，装了也转不起来。
