一些联合表查询语句，这些表里都建立有索引。在没有加 option ( force order ) 前，整个查询费时40多秒，但 单独表 查询基本不到1秒。查看查询计划后发现查询过程是从table n开始使用索引与 table s 等匹配，再与table m中的b匹配，导致整个查询最多表的扫描次数上千次多，逻辑读上万次。加了 option ( force order ) 后，最多表查询扫描次数在10次以内，逻辑读最多的也就千出头。整个查询费时不到1秒，CPU运行占用时间599MS。分享一下。
以下是详细解释：
OPTION 子句用于指定在整个查询过程中的查询提示（Query Hint）。通常，用户不必使用OPTION 子句，因为查询优化器会自动选择一个最佳的查询计划。OPTION 子句必须由最外层的主查询来指定。各查询提示之间应使用逗号隔开。其语法如下： OPTION (<query_hint> [,...n] )<query_hint> ::={ { HASH | ORDER } GROUP| { CONCAT | HASH | MERGE } UNION| { LOOP | MERGE | HASH } JOIN| FAST number_rows| FORCE ORDER| MAXDOP number| ROBUST PLAN| KEEP PLAN| KEEPFIXED PLAN| EXPAND VIEWS}各参数说明如下： {HASH | ORDER} GROUP指定在GROUP BY 或COMPUTE 子句中指定的查询使用散列法或排序法。所谓散列法是指为存储和检索数据项或数据，把搜索关键字转换为一个地址的一种方法。该方法常作为数据集内的记录的一种算法，可以使记录分组均匀，减少搜索时间。 {MERGE | HASH | CONCAT} UNION指定所有的UNION 操作符采用合并（Merge）、散列（Hash） 或连接（Concatenate）的方法执行操作。如果指定了多个UNION 提示，查询优化器会挑选一个最佳的提示方案。 {LOOP | MERGE | HASH |} JOIN指定查询过程中的所有连接操作采取循环连接（Loop Join）、合并连接（Merge Join）或散列连接（Hash Join） 的方法。如果指定了多个JOIN 提示，查询优化器会挑选一个最佳的提示方案。 FAST number_rows
指定查询优化只用于迅速返回前number_rows 行数据，在number_rows 行以后的数据采用原查询方法。 FORCE ORDER指定在查询语法中说明的连接顺序在查询优化的过程中保持不变。 MAXDOP number忽略由Sp_configure 设定的针对查询的最大并行线程数目。 ROBUST PLAN强制查询优化器尝试使用最大行容量的计划。 KEEP PLAN强制查询优化器放松重新编译查询的阈值。指定此选项可以让一个表被多次更新而不必频繁地重新编译查询。 KEEPFIXED PLAN强制查询优化器不重新编译查询。这样只有当表的概要改变或执行Sp_recompile 存储过程时，才会重新编译查询。 EXPAND VIEWS扩展索引化视图（当一个视图的名称在查询文本中被视图定义替换时称这个视图被扩展了），并且查询优化器不再将索引化视图作为查询的某部分的替代品。如果视图使用了WITH （NOEXPAND） 说明，则不能被扩展。
转载于:https://www.cnblogs.com/Fly-sky/p/5622421.html
