SQL存储过程复杂逻辑并行度优化技巧

存储过程从根本上来说并不支持内部并行执行，其本质是一段串行运行的SQL逻辑。所谓“提升并行度”，实际上是一个容易被误解的概念：并非让存储过程本身具备并行能力，而是让存储过程中包含的查询，能够被数据库优化器生成并行执行计划，或者通过外部手段将任务拆分成多个可以同时运行的存储过程实例。

因此，在明确这一前提后，我们来探讨一个常见的疑惑：为什么在存储过程中写一个简单的SELECT ... FROM big_table，却始终无法以并行方式运行？

在多数情况下，问题并非出在存储过程本身，而是优化器在幕后进行了“成本计算”——当它认为某个查询的代价不够高时，就不会启动并行。或者更直接地说，存在一些隐式抑制因素，直接阻断了并行路径。例如：

• WHERE col IN (SELECT ...) 这类嵌套子查询，优化器默认采用嵌套循环连接，而这种连接本质上就是串行的。
• 使用GETDATE()、标量UDF、TOP，或者一个没有索引的ORDER BY，都会强制禁用并行。
• 数据库的兼容级别也是一个变量。
• 最严重的情况：服务器级别的max degree of parallelism如果被设为1，相当于全局锁定，任何查询都无法并行执行。

那么，问题来了：如何才能让存储过程中的查询真正实现并行运行？

关键不在于修改存储过程的语法，而在于改变查询本身的结构和执行环境。以下是一些经验之谈：

• 将IN (SELECT ...)或EXISTS改写为JOIN，为优化器提供更多选择，例如哈希连接或合并连接。
• 确保关联字段上建有合适的索引，并且统计信息是最新的（UPDATE STATISTICS是常规操作）。
• 对于SQL Server 2016及以上版本，可以在调用时添加查询提示：OPTION (ENABLE_PARALLEL_PLAN_PREFERENCE)。
• 尽量避免在存储过程中使用DECLARE @var + SELECT ... INTO @var这种标量赋值模式，它会阻断并行分支。

MySQL这边的情况则略显尴尬。它的存储过程采用单线程执行模型，即便你使用WHILE循环或游标进行分批处理，也只能在一个连接内串行运行。想要实现“并行”，只能依靠外部调度：

• 在应用层启动多个线程，分别调用CALL sp_batch_update(1000, 'batch_01')、CALL sp_batch_update(1000, 'batch_02')……
• 或者使用mysql -e "CALL ..."启动多个shell进程，配合&后台运行。
• 不过需要注意：每个调用都是独立事务，数据一致性需要自行保证，例如通过唯一的batch_id来隔离范围。

Oracle在这方面则灵活得多。它允许在存储过程内部显式指定并行度，但前提是必须满足几个条件：

• 表本身需要启用并行属性：ALTER TABLE orders PARALLEL 4;
• 查询中需要添加Hint：SELECT /*+ PARALLEL(t, 4) */ * FROM orders t WHERE ...
• 或者在会话级别开启：ALTER SESSION ENABLE PARALLEL DML;（否则INSERT/UPDATE仍然不会走并行）
• 注意：PARALLEL Hint仅对扫描、连接、聚合等操作生效，对索引查找和小结果集基本没有作用。

真正容易被忽略的一点是：并行并非越多越好。在一台4核的机器上，为单个查询设置PARALLEL 16，往往会导致严重的资源争抢和I/O拥塞。因此，在下手之前，先查看V$PQ_SLA VE和AWR报告中的“PX wait events”，再根据实际情况进行调优，这才是正确的做法。