用并行查询让SQL Server加速运行

并行查询其优势就是可以通过多个线程来处理查询作业，从而提高查询的效率。SQL Server数据库为具有多个CPU的数据库服务器提供并行查询的功能，以优化查询作业的性能。也就是说，只要数据库服务器有多个CPU，则数据库系统就可以使用多个操作系统进程并行执行查询操作，来加速完成查询作业。

一、并行查询三步走。

并行查询作业在数据库中，主要经过三个步骤。

首先，数据库会判断是否需要进行并行查询。在数据库中有一个查询优化器，会对SQL语句进行优化，然后数据库才会去执行查询语句。而这个查询器在对SQL语句进行查询优化时，其中一个动作就是判断是否需要对SQL语句进行查询优化。也就是说，并不是所有的SQL查询语句都可以从并行查询中获取收益。如果查询优化器认为查询语句可以从并行查询中获取收益的话，则就会将交换运算符插入到查询执行计划中，为并行查询做准备。故哪些语句需要采用并行查询，哪些不需要，这不用数据库管理员关心。数据库查询优化器会帮管理员作出这个决定。数据库管理员需要清楚的是，在哪些情况下，数据库SQL优化器会认为不宜采用并行查询。通常情况下，只要满足以下条件的任何一个，则就不会执行并行查询。一是对于特定的查询，查询优化器认为串行查询执行计划要快于任何可能的并行执行计划;二是查询的串行执行成本并不高，不需要进行并行查询;三是查询中包含无法并行运行的标量运算符或者关系运算符。若从数据库管理员的角度讲，第三个条件对我们具有最大的影响。当数据库预计未来可能利用并行查询来提高数据库性能时，则在数据库设计时，就需要注意避免使用那些无法在并行查询功能中使用的运算符。因为某些关系运算符或者逻辑运算符可能会要求查询计划一定要在串行模式中进行，或者部分需要在串行模式下进行。如此的话，查询优化器就不会利用并行查询功能来提高查询语句的性能。这是数据库管理员在数据库设计时必须要考虑到的一个细节问题。

其次，确定并行的进程数。当查询优化器在查询语句中插入交叉运算符之后，数据库就会执行并行查询。并行查询在执行计划时可以使用多个线程。此时，就又遇到了一个问题，数据库会把这个查询作业分成几个进程操作呢?此时，数据库管理员就需要知道上什么叫做并行度。其实。在处理并行查询的时候，数据需要知道最大可使用的进程与实际使用的进程。而最大可使用的进程就叫做并行度。这个并行度的值是在服务器级别中进行设置，也可以通过系统存储过程来进行修改。但是，最大可使用进程数不一定等于实际是用进程数。实际是用进程数是数据库在查询计划执行时初始化的时候确定的。也就是说，这不用数据库管理员去额外的设定。数据库系统会自动根据计划的复杂程度来确定合理的进程数目。当然其实际采用的进程数不能够超过并行度，即最大可以使用的进程数。

最后执行查询。当以上内容确定好之后，数据库就会执行具体的查询语句。在这一步中，需要注意一个问题。数据库管理员还可以在查询语句中指定MAXDOP查询提示来修改这个进度值。也就是说，如果某个查询作业数据库管理员认为可能会耗时比较久，就可以为这个查询作业设置比较大的进度值。当利用MAXDOP查询提示设置这个并行进度值之后，它会覆盖预先设置的默认值。从而实现针对单个查询语句设置额外的进度值，以提高某些特殊查询作业的性能。

二、并行查询中需要注意的内容。

注意点一：需要注意硬件方面的限制。

并行查询是数据库提高查询性能的一个有力举措。不过其往往受到比较大的约束。如上面提高的一些基于成本考虑之外，还有一些硬性的限制。如通常情况下，只有在数据库服务器有多个微处理器(CPU )的情况下数据库才会考虑执行并行查询。也就是受，只有具有多个CPU的计算机才能够使用并行查询。这是一个硬性的限制条件。另外在查询计划执行过程中，数据库还会判断当时是否有足够多的线程可以使用。每个查询操作都要求一定的线程数才能够执行;而且执行并行计划比执行串行计划需要更多的线程，所需要的线程数也会随着并行度的提高而提高。如果在并行计划执行的时候，当时数据库服务器没有足够的线程让并行计划使用的话，数据库引擎就会自动减少并行度，甚至会放弃并行查询而改为串行计划。所以说，数据库是否能够执行并行查询，要受到其硬件的限制。为此，如果企业真的需要通过并行查询来提高数据库性能的话，则管理员就需要根据情况来调整硬件配置。

 

　　注意点二：不建议对所有查询都使用并行查询。

通常情况下，笔者认为最好只对大型表的连接查询、大量数据的聚合操作、大型结果集的重复排序等等操作才应用并行查询的功能。如果在这些操作上执行并行查询的话，那么其改善数据库性能的效果是非常明显的。相反，如果对于简单查询执行并行查询的话，可能执行并行查询所需要的额外协调工作会大于其潜在的性能提升。所以，数据库管理员在确定是否需要执行并行查询功能的话，需要慎重。笔者的建议是，在数据库服务器级别上，最好不要设置并行查询。即把并行度设置为1或者一个比较小的值。然后对于一些特殊的查询操作，利用MAXDOP查询提示来设置最大的可使用进程数。如此的话，可能会更加的合理。如果有时候数据库管理员不知道是否需要采用并行查询功能的话，则可以通过数据库自带的统计功能进行判断。为了区别并行查询计划到底有没有从并行查询中受益，数据库引擎可以将执行查询的估计开销与并行查询的开销阀值进行比较。并行计划只有对需时较长的查询通常更加有益;因为其性能优势将抵消初始化、同步和终止并行计划所需的额外时间开销。

注意点三：数据库会根据查询所涉及到的行数来判断是否要并行查询。

上面谈到，最好对大型表的连接查询、大量数据的聚合操作、大型结果集的重复排序等等操作才应用并行查询的功能。因为只有如此，并行查询带来的收益才会超过其付出的代价。但是，并不是说连接查询、聚合操作、排序等作业都适合采用并行查询。当数据库在考虑并行查询计划的时候，查询优化器还会去确定所涉及到的行数。如果所涉及到的行数台少，则将不会考虑执行并行查询计划。而会采用串行方式执行查询语句。如此的话，可以避免因为启动、分发、协调的开销大大超过并行执行作业所带来的收益。这本来是一个不错的设计，但是也会给数据库管理员带来一定的麻烦。如现在数据库管理员想要测试并行查询到底可以在多大程度上影响查询操作，就有点麻烦。因为其有数据量的限制。如果数据库管理员需要进行这个测试，还不得不先在数据库系统中导入足够多的数据才行。这就限制了数据库管理员的测试操作。不过话说回来，这个机制仍然是不错的。因为数据库管理员不用去考虑，当数据库规模到多大的时候采用并行查询。

注意点四：同一个操作在不同时候会采用不同的进程数。

上面说到过，并行查询到第采用多少进程数除了跟操作的复杂程度相关外，还直接跟当时的服务器状态相关，如是否有足够的进程数等等。所以，在不同的时间，即使是相同的数据、相同的操作，其并行查询所用的进程数也可能不同。其所需要的时间也就不同了。因为只有在并行查询真正进行的时候，数据库引擎才去收集当前系统的工作负荷，如进程数，和其他对一些配置信息，然后数据库才确定最佳的并行进程数。从查询开始，到这个查询作业结束，将一直采用这个进程数。如果下次要继续查询，则数据库引擎会继续收集这些信息。此时，如果系统工作负荷有所改善，在数据库可能会采用更多的进程数来执行这个查询。从而查询作业的性能会更加的高。相反，如果此时系统的负荷比前一次查询要重了，则数据库就可能会采用比较少的进程来处理这个作业。此时，第二次查询的速度反而更慢了。所以，如果在数据库服务器中同时部署了其他应用，则其他应用所占用系统资源的多少也会对并行执行产生难以估测的影响。