Oprava: Změna pořadí vnější spojení s kritérii filtru před neselektivní spojení a vnější spojení

CHYBA Č: 356418 (SHILOH_BUGS)

Příznaky

Pokud odešlete dotaz, který obsahuje alespoň jedno vnější spojení, která má podmínku filtru v klauzuli WHERE na vnitřní tabulka vnější spojení (například podmínku filtru na pravé tabulky levé vnější spojení nebo levé tabulky pravé vnější spojení), SQL Server může provést méně selektivní spojení nejprve včasné provádění vnější spojení a použití podmínku filtru. Pokud podmínka filtru z vnějšího spojení je jedním z více selektivní kritéria dotazu, nezpracování brzy v plánu kritéria mohou vést ke:
  • Větší velikosti vnitřní spojení.
  • Vyšší využití prostředků serveru SQL Server procesem.
  • Pomalejší doba odezvy dotazu.

Řešení

Řešení pro SQL Server 2005

Tento problém vyřešíte pomocí nejnovější aktualizace service pack pro SQL Server 2005. Další informace získáte v následujícím článku znalostní báze Microsoft Knowledge Base:
913089 jak získat nejnovější aktualizaci service pack pro SQL Server 2005
Po instalaci aktualizace service pack serveru SQL Server 2005, musíte zapnout příznak trasování 4101, chcete-li vyřešit tento problém.

Řešení pro SQL Server 2000

Tento problém vyřešíte pomocí nejnovější aktualizace service pack pro Microsoft SQL Server 2000. Další informace získáte v následujícím článku znalostní báze Microsoft Knowledge Base:
290211 jak získat nejnovější aktualizaci service pack pro SQL Server 2000
Poznámka: následující oprava hotfix byla vytvořena před vydáním Microsoft SQL Server 2000 Service Pack 3.

Anglická verze této opravy má následující atributy souborů nebo novější:
   Version       File name
-----------------------------

8.00.0584 Sqlservr.exe

Poznámka: vzhledem k závislostem souborů nejnovější opravy hotfix nebo funkce, která obsahuje soubory může také obsahovat další soubory.

Stav

Stav serveru SQL Server 2005

Společnost Microsoft potvrdila, že se jedná o problém v produktech společnosti Microsoft, které jsou uvedeny v části "Platí pro".
Tento problém byl poprvé opraven v Microsoft SQL Server 2005 Service Pack 1.

Stav serveru SQL Server 2000

Společnost Microsoft potvrdila, že se jedná o problém v produktech společnosti Microsoft, které jsou uvedeny v části "Platí pro".
Tento problém byl poprvé opraven v Microsoft SQL Server 2000 Service Pack 3.

Další informace

Následující scénář contrived spojení používá databázi pubs prokázat scénář:
set ansi_nulls offgo

use pubs
go

create procedure dbo.ansi_nulls_param @P1 varchar(11) as
select t.title_id, a.au_id, ta.title_id, s.stor_id from titles t
left outer join titleauthor ta on ta.title_id = t.title_id
inner join authors a on a.au_id = t.title_id
inner join sales s on s.title_id = t.title_id
where ta.title_id = @P1
go

exec dbo.ansi_nulls_param '123-45-6789'
go

drop proc dbo.ansi_nulls_param
go

--Slower Query Plan:
|--Filter(WHERE:([ta].[title_id]=[@P1]))
|--Nested Loops(Left Outer Join, OUTER REFERENCES:([t].[title_id]))
|--Nested Loops(Inner Join, OUTER REFERENCES:([s].[title_id]))
| |--Nested Loops(Inner Join, OUTER REFERENCES:([s].[title_id]))
| | |--Index Scan(OBJECT:([pubs].[dbo].[sales].[titleidind] AS [s]))
| | |--Clustered Index Seek(OBJECT:([pubs].[dbo].[authors].[UPKCL_auidind] AS [a]), SEEK:([a].[au_id]=[s].[title_id]) ORDERED FORWARD)
| |--Clustered Index Seek(OBJECT:([pubs].[dbo].[titles].[UPKCL_titleidind] AS [t]), SEEK:([t].[title_id]=[s].[title_id]) ORDERED FORWARD)
|--Index Seek(OBJECT:([pubs].[dbo].[titleauthor].[titleidind] AS [ta]), SEEK:([ta].[title_id]=[t].[title_id]) ORDERED FORWARD)

--Faster Query Plan:
|--Nested Loops(Inner Join, OUTER REFERENCES:([a].[au_id]))
|--Nested Loops(Inner Join, OUTER REFERENCES:([t].[title_id]))
| |--Filter(WHERE:([ta].[title_id]=[@P1]))
| | |--Nested Loops(Left Outer Join, OUTER REFERENCES:([t].[title_id]))
| | |--Index Scan(OBJECT:([pubs].[dbo].[titles].[titleind] AS [t]))
| | |--Index Seek(OBJECT:([pubs].[dbo].[titleauthor].[titleidind] AS [ta]), SEEK:([ta].[title_id]=[t].[title_id]) ORDERED FORWARD)
| |--Clustered Index Seek(OBJECT:([pubs].[dbo].[authors].[UPKCL_auidind] AS [a]), SEEK:([a].[au_id]=[t].[title_id]) ORDERED FORWARD)
|--Index Seek(OBJECT:([pubs].[dbo].[sales].[titleidind] AS [s]), SEEK:([s].[title_id]=[a].[au_id]) ORDERED FORWARD)

Všimněte si, že je v tabulce AutorKnihy (titleauthor) pravé tabulky levé vnější spojení a podmínky klauzule WHERE v AutorKnihy (titleauthor) , který má být použit po vnější spojení. Výstup ukazuje původní, pomalejší dotaz plánu, kde jsou nejprve provádět vnitřní spojení a vnější spojení a filtr se provádí poslední, i když je většina výběrové podmínky dotazu. Druhý plán dotazů je vynucené plán, který ukazuje, jak rychlejší plán vypadat, ve kterém vnější spojení a filtr je nejdříve provedena první, následované zbývající vnitřní spojení.

V tomto konkrétním scénáři optimalizace pokračuje k výběru prvního plánu i po instalaci opravy hotfix. Toto je, protože tyto tabulky jsou tak malé a odhadované náklady prvního plánu je natolik nízká, že je považováno za lepší než pokračovat v hledání dalších alternativ stačí spustit s tímto plánem. Data v tabulkách se zvyšuje náklady prvního plánu se vyšší a okně Optimalizace spuštění zvolte druhý plán.
Vlastnosti

ID článku: 318530 - Poslední kontrola: 16. 1. 2017 - Revize: 1

Váš názor