存储过程本身不支持内部并行执行，其串行本质决定并行需依赖底层查询能否生成并行计划；根本原因是优化器成本估算低于阈值，或存在GETDATE()、标量UDF、TOP、无索引ORDER BY等隐式抑制项。
存储过程本身不支持内部并行执行——它是一段串行执行的 SQL 逻辑，所谓“提升并行度”，实际是指让存储过程所依赖的底层查询能被优化器生成并行执行计划，或者通过外部手段把任务拆解为多个可并行运行的存储过程实例。
为什么存储过程里写个 SELECT ... FROM big_table 就跑不起来并行？
根本原因不是存储过程的问题，而是 SQL Server（或 Oracle、MySQL 8.0+）优化器对当前语句的成本估算低于并行阈值，或存在隐式抑制项：
-
WHERE col IN (SELECT ...)这类嵌套子查询默认触发嵌套循环连接，优化器倾向串行 - 用了
GETDATE()、标量 UDF、TOP、无索引的ORDER BY，会强制禁用并行 - 数据库兼容级别
- 服务器级
max degree of parallelism被设为 1，全局锁死
怎么让存储过程里的查询真正跑并行？
关键不是改存储过程语法，而是改查询结构和执行环境：
- 把
IN (SELECT ...)或EXISTS重写为JOIN，让优化器有机会选择哈希/合并连接 - 确保关联字段有合适索引，且统计信息最新（
UPDATE STATISTICS） - 在调用时加查询提示：
OPTION (ENABLE_PARALLEL_PLAN_PREFERENCE)（SQL Server 2016+） - 避免在存储过程中使用
DECLARE @var+SELECT ... INTO @var这种标量赋值模式，它会阻断并行分支
MySQL 存储过程能靠多线程提升并行度吗？
不能。MySQL 的存储过程是单线程执行模型，即使你用 WHILE 或游标分批处理，也只在一个连接内串行跑。想“并行”，只能靠外部调度：
- 应用层起多个线程，分别
CALL sp_batch_update(1000, 'batch_01')、CALL sp_batch_update(1000, 'batch_02')… - 用
mysql -e "CALL ..."启多个 shell 进程，配合&后台运行 - 注意：每个调用都是独立事务，需自行保证数据一致性（比如用唯一
batch_id隔离范围）
Oracle 存储过程中启用并行的正确姿势
Oracle 支持在存储过程内显式指定并行度，但必须满足前提：
- 表已启用并行属性：
ALTER TABLE orders PARALLEL 4; - 查询中加 Hint：
SELECT /*+ PARALLEL(t, 4) */ * FROM orders t WHERE ... - 或会话级开启：
ALTER SESSION ENABLE PARALLEL DML;（否则INSERT/UPDATE不走并行） - 注意：
PARALLELHint 只对扫描、连接、聚合类操作生效，对索引查找、小结果集无效
真正容易被忽略的点是：并行不是越多越好。一个 4 核机器上给单个查询配 PARALLEL 16，反而引发严重争抢和 I/O 拥塞。先看 V$PQ_SLAVE 和 AWR 报告里的“PX wait events”，再调。
