注意点二：不建议对所有查询都使用并行查询。
通常情况下，笔者认为最好只对大型表的连接查询、大量数据的聚合操作、大型结果集的重复排序等等操作才应用并行查询的功能。如果在这些操作上执行并行查询的话，那么其改善数据库性能的效果是非常明显的。相反，如果对于简单查询执行并行查询的话，可能执行并行查询所需要的额外协调工作会大于其潜在的性能提升。所以，数据库管理员在确定是否需要执行并行查询功能的话，需要慎重。笔者的建议是，在数据库服务器级别上，最好不要设置并行查询。即把并行度设置为1或者一个比较小的值。然后对于一些特殊的查询操作，利用MAXDOP查询提示来设置最大的可使用进程数。如此的话，可能会更加的合理。如果有时候数据库管理员不知道是否需要采用并行查询功能的话，则可以通过数据库自带的统计功能进行判断。为了区别并行查询计划到底有没有从并行查询中受益，数据库引擎可以将执行查询的估计开销与并行查询的开销阀值进行比较。并行计划只有对需时较长的查询通常更加有益;因为其性能优势将抵消初始化、同步和终止并行计划所需的额外时间开销。
注意点三：数据库会根据查询所涉及到的行数来判断是否要并行查询。
上面谈到，最好对大型表的连接查询、大量数据的聚合操作、大型结果集的重复排序等等操作才应用并行查询的功能。因为只有如此，并行查询带来的收益才会超过其付出的代价。但是，并不是说连接查询、聚合操作、排序等作业都适合采用并行查询。当数据库在考虑并行查询计划的时候，查询优化器还会去确定所涉及到的行数。如果所涉及到的行数台少，则将不会考虑执行并行查询计划。而会采用串行方式执行查询语句。如此的话，可以避免因为启动、分发、协调的开销大大超过并行执行作业所带来的收益。这本来是一个不错的设计，但是也会给数据库管理员带来一定的麻烦。如现在数据库管理员想要测试并行查询到底可以在多大程度上影响查询操作，就有点麻烦。因为其有数据量的限制。如果数据库管理员需要进行这个测试，还不得不先在数据库系统中导入足够多的数据才行。这就限制了数据库管理员的测试操作。不过话说回来，这个机制仍然是不错的。因为数据库管理员不用去考虑，当数据库规模到多大的时候采用并行查询。
注意点四：同一个操作在不同时候会采用不同的进程数。
上面说到过，并行查询到第采用多少进程数除了跟操作的复杂程度相关外，还直接跟当时的服务器状态相关，如是否有足够的进程数等等。所以，在不同的时间，即使是相同的数据、相同的操作，其并行查询所用的进程数也可能不同。其所需要的时间也就不同了。因为只有在并行查询真正进行的时候，数据库引擎才去收集当前系统的工作负荷，如进程数，和其他对一些配置信息，然后数据库才确定最佳的并行进程数。从查询开始，到这个查询作业结束，将一直采用这个进程数。如果下次要继续查询，则数据库引擎会继续收集这些信息。此时，如果系统工作负荷有所改善，在数据库可能会采用更多的进程数来执行这个查询。从而查询作业的性能会更加的高。相反，如果此时系统的负荷比前一次查询要重了，则数据库就可能会采用比较少的进程来处理这个作业。此时，第二次查询的速度反而更慢了。所以，如果在数据库服务器中同时部署了其他应用，则其他应用所占用系统资源的多少也会对并行执行产生难以估测的影响。
文章来源于领测软件测试网 https://www.ltesting.net/
