sql 执行计划问题

anlinew

SQL server 关于这个问题的fix
http://support.microsoft.com/kb/318530/en-us

FIX: Reorder outer joins with filter criteria before non-selective joins and outer joins
View products that this article applies to.
This article was previously published under Q318530
BUG #: 356418 (SHILOH_BUGS)
On This PageSYMPTOMS
RESOLUTION
Resolution for SQL Server 2005
Resolution for SQL Server 2000
STATUS
Status for SQL Server 2005
Status for SQL Server 2000
MORE INFORMATION
Expand all | Collapse all
SYMPTOMSIf you submit a query that contains at least one outer join that has a filter co...If you submit a query that contains at least one outer join that has a filter condition in the WHERE clause on the inner table of the outer join (for example, a filter condition on the right table of a left outer join, or the left table of a right outer join), SQL Server may perform less selective joins first instead of performing the outer join early and applying the filter condition. If the filter condition from the outer join is one of the more selective criteria for the query, failing to process the criteria early in the plan may lead to:
Larger intermediate join sizes.
Higher resource utilization by the SQL Server process.
Slower response time for the query.
Back to the top
RESOLUTIONResolution for SQL Server 2005To resolve this problem, obtain the latest service...Resolution for SQL Server 2005
To resolve this problem, obtain the latest service pack for SQL Server 2005. For more information, click the following article number to view the article in the Microsoft Knowledge Base:
913089  (http://support.microsoft.com/kb/913089/ ) How to obtain the latest service pack for SQL Server 2005
After you install the SQL Server 2005 service pack, you must turn on trace flag 4101 to resolve this problem.
Back to the top
Resolution for SQL Server 2000
To resolve this problem, obtain the latest service pack for Microsoft SQL Server 2000. For more information, click the following article number to view the article in the Microsoft Knowledge Base:
290211  (http://support.microsoft.com/kb/290211/ ) How to obtain the latest SQL Server 2000 service pack
NOTE: The following hotfix was created before the release of Microsoft SQL Server 2000 Service Pack 3.

The English version of this fix should have the following file attributes or later:
   Version       File name
   -----------------------------

   8.00.0584     Sqlservr.exe
                               

NOTE: Because of file dependencies, the most recent hotfix or feature that contains the files may also contain additional files.


Back to the top
STATUSStatus for SQL Server 2005Microsoft has confirmed that this is a problem in the...Status for SQL Server 2005
Microsoft has confirmed that this is a problem in the Microsoft products that are listed in the "Applies to" section.
This problem was first corrected in Microsoft SQL Server 2005 Service Pack 1.
Back to the top
Status for SQL Server 2000
Microsoft has confirmed that this is a problem in the Microsoft products that are listed in the "Applies to" section.
This problem was first corrected in Microsoft SQL Server 2000 Service Pack 3.
Back to the top
MORE INFORMATIONThe following contrived join scenario uses the pubs database to demonstrate the...The following contrived join scenario uses the pubs database to demonstrate the scenario:

1. 
   
2. 
   
3. set ansi_nulls off
   
4. go
   
5. 
   
6. use pubs
   
7. go
   
8. 
   
9. create procedure dbo.ansi_nulls_param @P1 varchar(11) as
   
10. select t.title_id, a.au_id, ta.title_id, s.stor_id from titles t
    
11.    left outer join titleauthor ta on ta.title_id = t.title_id
    
12.    inner join authors a on a.au_id = t.title_id
    
13.    inner join sales s on s.title_id = t.title_id
    
14. where ta.title_id = @P1
    
15. go
    
16. 
    
17. exec dbo.ansi_nulls_param '123-45-6789'
    
18. go
    
19. 
    
20. drop proc dbo.ansi_nulls_param
    
21. go
    
22. 
    
23. --Slower Query Plan:[color=Red]
    
24.        |--Filter(WHERE:([ta].[title_id]=[@P1]))
    
25.             |--Nested Loops(Left Outer Join, OUTER REFERENCES:([t].[title_id]))
    
26.                  |--Nested Loops(Inner Join, OUTER REFERENCES:([s].[title_id]))
    
27.                  |    |--Nested Loops(Inner Join, OUTER REFERENCES:([s].[title_id]))
    
28.                  |    |    |--Index Scan(OBJECT:([pubs].[dbo].[sales].[titleidind] AS [s]))
    
29.                  |    |    |--Clustered Index Seek(OBJECT:([pubs].[dbo].[authors].[UPKCL_auidind] AS [a]), SEEK:([a].[au_id]=[s].[title_id]) ORDERED FORWARD)
    
30.                  |    |--Clustered Index Seek(OBJECT:([pubs].[dbo].[titles].[UPKCL_titleidind] AS [t]), SEEK:([t].[title_id]=[s].[title_id]) ORDERED FORWARD)
    
31.                  |--Index Seek(OBJECT:([pubs].[dbo].[titleauthor].[titleidind] AS [ta]), SEEK:([ta].[title_id]=[t].[title_id]) ORDERED FORWARD)
    
32. 
    
33. --Faster Query Plan:
    
34.        |--Nested Loops(Inner Join, OUTER REFERENCES:([a].[au_id]))
    
35.             |--Nested Loops(Inner Join, OUTER REFERENCES:([t].[title_id]))
    
36.             |    |--Filter(WHERE:([ta].[title_id]=[@P1]))
    
37.             |    |    |--Nested Loops(Left Outer Join, OUTER REFERENCES:([t].[title_id]))
    
38.             |    |         |--Index Scan(OBJECT:([pubs].[dbo].[titles].[titleind] AS [t]))
    
39.             |    |         |--Index Seek(OBJECT:([pubs].[dbo].[titleauthor].[titleidind] AS [ta]), SEEK:([ta].[title_id]=[t].[title_id]) ORDERED FORWARD)
    
40.             |    |--Clustered Index Seek(OBJECT:([pubs].[dbo].[authors].[UPKCL_auidind] AS [a]), SEEK:([a].[au_id]=[t].[title_id]) ORDERED FORWARD)
    
41.             |--Index Seek(OBJECT:([pubs].[dbo].[sales].[titleidind] AS [s]), SEEK:([s].[title_id]=[a].[au_id]) ORDERED FORWARD)[/color]
    
42.                                
    

复制代码

Note that the titleauthor table is the right table of a left outer join and the WHERE clause condition on titleauthor that is to be applied after the outer join. The output shows the original, slower query plan, where all the inner joins are performed first and the outer join and filter is performed last, even though it is the most selective condition for the query. The second query plan is a forced plan that demonstrates what the faster plan will look like, in which the outer join and filter is performed first, followed by the remaining inner joins.

For this particular scenario, the optimizer continues to choose the first plan even after you apply the hotfix. This is because these tables are so small and the estimated cost of the first plan is low enough that it is deemed better to just run with that plan than it is to continue searching for subsequent alternatives. As the data in the tables increases, the cost of the first plan becomes higher and the optimizer starts to choose the second plan.

[ 本帖最后由 anlinew 于 2010-6-17 17:02 编辑 ]

anlinew

ansinull option [compatibility]
Controls the interpretation of NULL values.

Allowed values
On, Off

Default
On

Remarks
This option is implemented primarily for Transact-SQL (Adaptive Server Enterprise) compatibility. The ansinull option affects the results of comparison predicates with NULL constants, and also affects warnings issued for grouped queries over NULL values.

With ansinull set to On, ANSI three-valued logic is used for all comparison predicates in a WHERE or HAVING clause, or in an On condition. Any comparisons with NULL using = or != evaluate to unknown.

Setting ansinull to Off means that SQL Anywhere uses two-valued logic for the following four conditions:

expr = NULL

expr != NULL

expr = @var // @var is a procedure variable, or a host variable

expr != @var

In each case, the predicate evaluates to either true or false—never unknown. In such comparisons, the NULL value is treated as a special value in each domain, and an equality (=) comparison of two NULL values yields true. Note that the expression expr must be a relatively simple expression, referencing only columns, variables, and literals; subqueries and functions are not permitted.

With ansinull set to On, the evaluation of any aggregate function, except COUNT(*), on an expression that contains at least one NULL value, may generate the warning null value eliminated in aggregate function (SQLSTATE=01003). With ansinull set to Off, this warning does not appear.

Limitations
Setting ansinull to Off affects only WHERE, HAVING, or ON predicates in SELECT, UPDATE, DELETE, and INSERT statements. The semantics of comparisons in a CASE or IF statement, or in IF expressions, are unaffected.

Adaptive Server Enterprise 12.5 introduced a change in the behavior of LIKE predicates with a NULL pattern string when ansinull is set to Off. In SQL Anywhere, LIKE predicates remain unaffected by the setting of ansinull.

anlinew

sql server下

ansinull  为OFF时出现问题可以理解为绑定变量值可能出现空字符串''的情况，而=''在ansinull 为off时相当于 is null ，这种情况下left out join显然是不能转换为inner join 的，如果数据库引擎对绑定变量赋值不做任何判断处理，甚至优化器都不考虑ansinull 参数的话，自然就会出现这个问题

但实际上数据库引擎是会对赋值做一些处理的，比如赋值的长度实际上是可能会导致选择不同的执行计划，因此SQL server 最终修正了这个问题

我相信ASE也可以或者说已经修正这个问题，期待熟悉ASE的给看看

5个周

我想研究一下，但是有没有人能给我一个SQL Server的建pub库的脚本文件啊？