Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
 В представлении оптимизатор не видит индексов  [new]
_ч_
Member

Откуда:
Сообщений: 1440
[/SRC]Может быть кто-то сталкивался с такой вот проблемой.

Есть две таблицы:

[src]CREATE TABLE [_cur](
	ID bigint NOT null,
	[processed] [datetime] NOT NULL
 CONSTRAINT [pk_cur] PRIMARY KEY CLUSTERED 
(
	ID ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [transaction_current]
)


CREATE TABLE [_old](
	ID bigint NOT null,
	[processed] [datetime] NOT NULL
 CONSTRAINT [pk_old] PRIMARY KEY CLUSTERED 
(
	ID ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [transaction_current]
)


На каждой таблице некластерные индексы по полю processed:
CREATE NONCLUSTERED INDEX [idx_cur_processed] ON [_cur]
(
	[processed] DESC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [transaction_current]



Есть вьюха:

CREATE view MyView
as
select * from _cur
union
select * from _old



Так вот, когда мы пишем запрос:

select top 10 * from _cur
order by processed desc


План запроса строиться по индексу idx_cur_processed (или idx_old_processed соответственно).

А когда мы пишем так:
select top 10 * from MyView order by processed desc

Происходит clustered index scan.


Как мне добиться того, чтобы для этой вьюхи оптимизатор видел нужные индексы по полю processed?


Select @@version
Microsoft SQL Server 2012 - 11.0.2100.60 (X64) 
	Feb 10 2012 19:39:15 
	Copyright (c) Microsoft Corporation
	Enterprise Edition (64-bit) on Windows NT 6.1 <X64> (Build 7601: Service Pack 1)
12 апр 13, 18:23    [14174788]     Ответить | Цитировать Сообщить модератору
 Re: В представлении оптимизатор не видит индексов  [new]
_ч_
Member

Откуда:
Сообщений: 1440
Sorry, вьюха выглядит вот так:

CREATE view MyView 
as

select * from _cur with (nolock)
union all
select * from _old with (nolock)
12 апр 13, 18:25    [14174797]     Ответить | Цитировать Сообщить модератору
 Re: В представлении оптимизатор не видит индексов  [new]
Glory
Member

Откуда:
Сообщений: 104751
_ч_
Как мне добиться того, чтобы для этой вьюхи оптимизатор видел нужные индексы по полю processed?

И как по каждому индексу оптимизатор выберет _общие_ top 10 ?
12 апр 13, 18:31    [14174811]     Ответить | Цитировать Сообщить модератору
 Re: В представлении оптимизатор не видит индексов  [new]
_ч_
Member

Откуда:
Сообщений: 1440
Glory,

у меня тоже возникли такие же сомнения.
И что же теперь делать? Не использовать union all во вьюхе?
12 апр 13, 18:34    [14174820]     Ответить | Цитировать Сообщить модератору
 Re: В представлении оптимизатор не видит индексов  [new]
Гость333
Member

Откуда:
Сообщений: 3683
_ч_
А когда мы пишем так:
select top 10 * from MyView order by processed desc

Происходит clustered index scan.

Пишите вот так:
select top 10 *
from
(
   select top 10 * from _old order by processed desc
   union all
   select top 10 * from _cur order by processed desc
) t
order by t.processed desc

С такой вьюхой на таком запросе каши не сваришь...
12 апр 13, 18:36    [14174827]     Ответить | Цитировать Сообщить модератору
 Re: В представлении оптимизатор не видит индексов  [new]
Shakill
Member

Откуда: мск
Сообщений: 1882
_ч_
у меня тоже возникли такие же сомнения.
И что же теперь делать? Не использовать union all во вьюхе?

если допустимо изменение структуры, то можно данные хранить в одной таблице вместо двух,
только надо будет добавить еще поле с признаком
12 апр 13, 18:38    [14174833]     Ответить | Цитировать Сообщить модератору
 Re: В представлении оптимизатор не видит индексов  [new]
_ч_
Member

Откуда:
Сообщений: 1440
Гость333,

дело в том, что там не только индекс по полю processed. И order by может быть по другим полям.
12 апр 13, 18:44    [14174845]     Ответить | Цитировать Сообщить модератору
 Re: В представлении оптимизатор не видит индексов  [new]
_ч_
Member

Откуда:
Сообщений: 1440
Shakill,

т.е. принципиально невозможно сделать так, чтобы оптимизатор приминил к этой вьюхе два индекса для каждой из таблиц?
Надо менять структуру?
12 апр 13, 18:45    [14174848]     Ответить | Цитировать Сообщить модератору
 Re: В представлении оптимизатор не видит индексов  [new]
Glory
Member

Откуда:
Сообщений: 104751
_ч_
т.е. принципиально невозможно сделать так, чтобы оптимизатор приминил к этой вьюхе два индекса для каждой из таблиц?

Каким образом, если серверу все равно придется упорядочить общий набор записей ?
12 апр 13, 18:47    [14174853]     Ответить | Цитировать Сообщить модератору
 Re: В представлении оптимизатор не видит индексов  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31863
Glory
_ч_
т.е. принципиально невозможно сделать так, чтобы оптимизатор приминил к этой вьюхе два индекса для каждой из таблиц?

Каким образом, если серверу все равно придется упорядочить общий набор записей ?
Ну в принципе оптимизатор мог бы использовать 2 индекса так же, как использовал Гость333. Но он так не делает, не заложен такой вариант...
_ч_
Надо менять структуру?
Как я понимаю, эта структура сделана для ускорения работы сервера, типа душевная идея разделить базу на оперативную и архивную?

Это очередная иллюстрация того, что такое разделение в лучшем случае не делает хуже :-)
12 апр 13, 20:07    [14175087]     Ответить | Цитировать Сообщить модератору
 Re: В представлении оптимизатор не видит индексов  [new]
_ч_
Member

Откуда:
Сообщений: 1440
Glory,

Вы как всегда правы.

Значит ситуация очень плохая, т.к. индексы на представления с UNION ALL тоже не повесишь.
15 апр 13, 10:08    [14179993]     Ответить | Цитировать Сообщить модератору
 Re: В представлении оптимизатор не видит индексов  [new]
SomewhereSomehow
Member

Откуда: Moscow
Сообщений: 2480
Блог
_ч_,

Оптимизатор может использовать два некластерных индекса из двух таблиц.
Например, мог бы получиться вот такой план:
Картинка с другого сайта.

По каждому некластерному индексу выполняется упорядоченный просмотр, после чего merge и ограничение топ. В чем вопрос, не понял.

К сообщению приложен файл (1.sqlplan - 5Kb) cкачать
15 апр 13, 16:32    [14182863]     Ответить | Цитировать Сообщить модератору
 Re: В представлении оптимизатор не видит индексов  [new]
Glory
Member

Откуда:
Сообщений: 104751
SomewhereSomehow
Оптимизатор может использовать два некластерных индекса из двух таблиц.
Например, мог бы получиться вот такой план:

Имхо
Для этого нужно очень точно проводить оценку данных.
Может оказаться, что ТОР превышает число записей в обеих таблицах
15 апр 13, 16:41    [14182948]     Ответить | Цитировать Сообщить модератору
 Re: В представлении оптимизатор не видит индексов  [new]
_ч_
Member

Откуда:
Сообщений: 1440
SomewhereSomehow,

Вопрос в том, что выбирается вот такой вот план:

|--Top(TOP EXPRESSION:((50)))
|--Merge Join(Concatenation)
|--Sort(ORDER BY:([cq].[processed] ASC, [cq].[bonus] ASC, [cq].[Id] ASC))
| |--Clustered Index Scan(OBJECT:([_old].[pk_old] AS [cq]))
|--Sort(ORDER BY:([cq].[processed] ASC, [cq].[bonus] ASC, [cq].[Id] ASC))
|--Clustered Index Scan(OBJECT:([_cur].[pk_cur] AS [cq]))


Вместо Вашего. Если бы был выбран Ваш, было бы всё в порядке. Т.е. проиходит сканирование по кластерным индексам pk_cur и pk_old, вместо более быстрого решения (сканирование по некластерным индексам idx_cur_processed и idx_old_processed).

К сообщению приложен файл. Размер - 44Kb
15 апр 13, 17:39    [14183358]     Ответить | Цитировать Сообщить модератору
 Re: В представлении оптимизатор не видит индексов  [new]
SomewhereSomehow
Member

Откуда: Moscow
Сообщений: 2480
Блог
Glory,
Безусловно. Точная оценка всегда важна.

_ч_,
Судя по форме плана, есть подозрение, что те скрипты, которые вы привели могут отличаться от реальных.

В тех что вы приведены у вас:
- Два поля в таблице
- ID - ключ кластерного индекса.
- processed - ключ некластерного (в который включен кластерный по-умолчанию)

Когда вы делаете "select *" - оптимизатору все равно из какого индекса выбирать, чтобы избежать Lookup (все поля есть во всех индексах), но не все равно какой выбирать из-за порядка сортировки. По этому, выбирается тот, что который может гарантировать сортировку при сканировании, в данном случае idx_XXX_processed.

Но если условия не соблюдаются, например, какой-то из индексов, не содержит все поля, то оптимизатор может выбирать из следующих вариантов:
1. Сканировать кластерный (который содержит все поля), потом отсортировать (дорогая операция)
2. Избежать сортировки сканировав некластерный индекс, но в нужном порядке, и уже потом сделать Lookup из кластерного для недостающих полей (очень дорогая операция)
Плюс добавить в уравнение то, что оптимизатор основывается на статистике, которая не всегда актуальна.

Может быть он выбирает первый вариант, как менее затратный? Lookup очень дорого.

Попробуйте, ради эксперимента поиграть с числом в TOP, например TOP(1) или TOP(2) тоже выберет план со сканом кластерного? Если да, то, наверное, без анализа планов не обойтись. Публикуйте сюда планы в виде xml, будем смотреть на оценки, о чем говорил Glory.

Если же, при малом числе строк выбирается nonclustered index scan + key lookup, но как только число строк возрастает план скатывается в скан кластерного индекса - значит дело в этом. В таком случае, необходимо индекс делать покрывающим (т.е. добавить в него все поля которые участвуют в запросе).

Вот какие планы были бы возможны.
Подготовка:
use tempdb;
go
CREATE TABLE [_cur](ID bigint NOT null, [processed] [datetime] NOT NULL, lookup_field int, CONSTRAINT [pk_cur] PRIMARY KEY CLUSTERED (ID ASC));
CREATE TABLE [_old](ID bigint NOT null, [processed] [datetime] NOT NULL, lookup_field int, CONSTRAINT [pk_old] PRIMARY KEY CLUSTERED (ID ASC));
go
CREATE NONCLUSTERED INDEX [idx_cur_processed] ON [_cur]([processed] DESC);
CREATE NONCLUSTERED INDEX [idx_cur_processed] ON [_old]([processed] DESC);
go
CREATE view MyView 
as
select * from _cur with (nolock)
union all
select * from _old with (nolock)
;
go
--simulate data
update statistics [_cur] with rowcount = 10000, pagecount = 100
update statistics [_old] with rowcount = 100000, pagecount = 1000
go

Запросы:
-- both clustered scan and sort
select top (50000) * from MyView order by processed desc;
go
-- one clustered scan and sort + one nonclustered scan and lookup
select top (5000) * from MyView order by processed desc;
go
-- both nonclustered scan and lookup
select top (500) * from MyView order by processed desc;
go

Планы:
Картинка с другого сайта.

Можно сделать покрывающие индексы и повторить запросы:
--possible workaround - create 2 covering indexex
create index idx_cur_processed_covering on [_cur]([processed] desc) include (lookup_field);
create index idx_old_processed_covering on [_old]([processed] desc) include (lookup_field);
exec sp_refreshview 'MyView' --might be important if no schema binding and table changings
go
-- both clustered scan and sort
select top (50000) * from MyView order by processed desc;
go
-- one clustered scan and sort + one nonclustered scan and lookup
select top (5000) * from MyView order by processed desc;
go
-- both nonclustered scan and lookup
select top (500) * from MyView order by processed desc;
go
--clear
drop view MyView;
drop table [_cur], [_old];

Планы:
Картинка с другого сайта.

П.С.
Если вам это не поможет, то выкладывайте сюда планы (только не картинками как я, т.к. в моем случае, реальные планы могут воспроизвести любые желающие, запустив скрипты, а свои реальные планы в формате xml, реальные еще и в том смысле, что не estimated (оценочные), а actual (реальные или актуальные), чтобы можно было сравнить оценки и действительность).
15 апр 13, 19:31    [14183876]     Ответить | Цитировать Сообщить модератору
 Re: В представлении оптимизатор не видит индексов  [new]
_ч_
Member

Откуда:
Сообщений: 1440
SomewhereSomehow,

Спасибо за заинтересованность, всё оказалось довольно запутанее.

Вот скрипт на создание таблиц и заполнение (заполняется только одна):

--Dropping tables if they exist
IF OBJECT_ID('test_a') IS NOT NULL
	DROP TABLE test_a

IF OBJECT_ID('test_b') IS NOT NULL
	DROP TABLE test_b

--Creating tables
CREATE TABLE loyalty.test_a(ID uID NOT NULL, summ DECIMAL(18, 2) NOT NULL, name NVARCHAR(40) NOT NULL, processed DATETIME NOT NULL
CONSTRAINT [pk_a] PRIMARY KEY CLUSTERED 
(
 ID ASC 
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON)
)


CREATE TABLE test_b(ID uID NOT NULL, summ DECIMAL(18, 2) NOT null, name NVARCHAR(40) NOT null, processed DATETIME NOT null
CONSTRAINT [pk_b] PRIMARY KEY CLUSTERED 
(
 ID ASC 
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON)
)

--Filling our tables
DECLARE @i INT = 0

WHILE @i < 4000
BEGIN
	INSERT INTO test_a (
		summ
		,NAME
		,processed
		)
	SELECT CONVERT(DECIMAL(18, 2), Column_id)
		,c.NAME
		,DATEADD(DAY, @i, o.modify_date)
	FROM sys.columns c
	JOIN sys.objects o ON o.object_id = c.object_id

	SET @i = @i + 1
END

--Creating indexes

CREATE NONCLUSTERED INDEX [idx_test_a_processed] ON test_a
(
	processed DESC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON)

CREATE NONCLUSTERED INDEX [idx_test_b_processed] ON test_b
(
	processed DESC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON)


--Dropping view if it exists
IF EXISTS(SELECT 1 FROM sys.views WHERE name = 'test_all')
	DROP VIEW test_all

SET ANSI_NULLS ON
GO

SET QUOTED_IDENTIFIER ON
GO

--Creating view
CREATE view [test_all]
AS
	SELECT ID
			,summ
			,name
			,processed
	FROM test_b WITH (NOLOCK)
	UNION ALL
	SELECT ID
			,summ
			,name
			,processed
	FROM test_a WITH (NOLOCK)
GO



А теперь я запускаю три простых запроса (с top 50 как и на боевой базе):

SELECT TOP 50 * FROM test_a
ORDER BY processed

SELECT TOP 50 * FROM dbo.test_all
ORDER BY processed DESC


SELECT TOP 50 * from dbo.test_all
ORDER BY processed ASC


К сообщению приложен файл (plan.xml - 73Kb) cкачать
16 апр 13, 10:00    [14185429]     Ответить | Цитировать Сообщить модератору
 Re: В представлении оптимизатор не видит индексов  [new]
Glory
Member

Откуда:
Сообщений: 104751
SomewhereSomehow
Glory,
Безусловно. Точная оценка всегда важна.

На мой взгляд, это уже больше похоже на секционирование.
Которое и так уже есть.
16 апр 13, 10:02    [14185437]     Ответить | Цитировать Сообщить модератору
 Re: В представлении оптимизатор не видит индексов  [new]
_ч_
Member

Откуда:
Сообщений: 1440
Так вот, из плана хорошо видно, что

в случае запроса

select top 50 * from test_all
order by processed desc


Оптимизатор сканирует некластерный индекс, а в случае:

select top 50 * from test_all
order by processed asc


сканирует уже кластерный.

Если поменять в некластерном индексе сортировку, то ситуация повториться с точностью до наоборот.
Если же сделать два некластерных индекса по полю procressed с сортировкой asc и desc, то план запроса строиться на сканировании только этих некластерных индексов.

Всё это происходит на двух серверах 2012.

select @@version
Microsoft SQL Server 2012 - 11.0.2100.60 (X64) 
	Feb 10 2012 19:39:15 
	Copyright (c) Microsoft Corporation
	Enterprise Edition (64-bit) on Windows NT 6.1 <X64> (Build 7601: Service Pack 1)


Сейчас буду ставить SP1 и тестировать там эту особенность поведения оптимизатора.

К сообщению приложен файл. Размер - 58Kb
16 апр 13, 10:07    [14185476]     Ответить | Цитировать Сообщить модератору
 Re: В представлении оптимизатор не видит индексов  [new]
Мистер Хенки
Member

Откуда: канализация
Сообщений: 6615
А не желаете в некластерный индекс добавить в виде include полей summ и name, чтобы не тратить ресурсы на операцию key lookup ?
16 апр 13, 10:48    [14185711]     Ответить | Цитировать Сообщить модератору
 Re: В представлении оптимизатор не видит индексов  [new]
_ч_
Member

Откуда:
Сообщений: 1440
Мистер Хенки,

В данном случае меня интересует вопрос как так получилось, что порядок сортировки в индексе и запросе влияет на выбор оптимизатора.
16 апр 13, 10:53    [14185737]     Ответить | Цитировать Сообщить модератору
 Re: В представлении оптимизатор не видит индексов  [new]
Мистер Хенки
Member

Откуда: канализация
Сообщений: 6615
_ч_
Мистер Хенки,

В данном случае меня интересует вопрос как так получилось, что порядок сортировки в индексе и запросе влияет на выбор оптимизатора.

потому что merge выдаст поток данных отсортированный в desc порядке(порядок у индексов) и надо будет еще его сортировать, чтобы сделать order by asc- как то так видимо. Если создадите покрывающие индексы, то увидете, что оптимизатор выберет их использование, но все равно будет сортировать перед merge join
16 апр 13, 11:22    [14185907]     Ответить | Цитировать Сообщить модератору
 Re: В представлении оптимизатор не видит индексов  [new]
_ч_
Member

Откуда:
Сообщений: 1440
Мистер Хенки,

воспользовался Вашим советом.

Теперь планы выглядят так:

SELECT TOP 50 name, id, processed, summ FROM dbo.test_all2
ORDER BY processed DESC	1	1	0	NULL	NULL	1	NULL	50	NULL	NULL	NULL	1,360734	NULL	NULL	SELECT	0	NULL
  |--Top(TOP EXPRESSION:((50)))	1	2	1	Top	Top	TOP EXPRESSION:((50))	NULL	50	0	5E-06	76	1,360734	[Union1006], [Union1007], [Union1008], [Union1009]	NULL	PLAN_ROW	0	1
       |--Merge Join(Concatenation)	1	3	2	Merge Join	Concatenation	NULL	[Union1009] = ([DB].[dbo].[test_b2].[processed], [DB].[dbo].[test_a2].[processed]), [Union1006] = ([DB].[dbo].[test_b2].[ID], [DB].[dbo].[test_a2].[ID]), [Union1007] = ([DB].[dbo].[test_b2].[summ], [DB].[dbo].[test_a2].[summ]), [Union1008] = ([DB].[dbo].[test_b2].[name], [DB].[dbo].[test_a2].[name])	50	0	1,336834	76	1,360729	[Union1009], [Union1006], [Union1007], [Union1008]	NULL	PLAN_ROW	0	1
            |--Sort(ORDER BY:([DB].[dbo].[test_b2].[processed] DESC, [DB].[dbo].[test_b2].[ID] ASC))	1	4	3	Sort	Sort	ORDER BY:([DB].[dbo].[test_b2].[processed] DESC, [DB].[dbo].[test_b2].[ID] ASC)	NULL	1	0,01126126	0,000100076	76	0,01464444	[DB].[dbo].[test_b2].[ID], [DB].[dbo].[test_b2].[summ], [DB].[dbo].[test_b2].[name], [DB].[dbo].[test_b2].[processed]	NULL	PLAN_ROW	0	1
            |    |--Index Scan(OBJECT:([DB].[dbo].[test_b2].[idx_test_b_processed]))	1	5	4	Index Scan	Index Scan	OBJECT:([DB].[dbo].[test_b2].[idx_test_b_processed])	[DB].[dbo].[test_b2].[ID], [DB].[dbo].[test_b2].[summ], [DB].[dbo].[test_b2].[name], [DB].[dbo].[test_b2].[processed]	1	0,003125	0,0001581	76	0,0032831	[DB].[dbo].[test_b2].[ID], [DB].[dbo].[test_b2].[summ], [DB].[dbo].[test_b2].[name], [DB].[dbo].[test_b2].[processed]	NULL	PLAN_ROW	0	1
            |--Sort(ORDER BY:([DB].[dbo].[test_a2].[processed] DESC, [DB].[dbo].[test_a2].[ID] ASC))	1	6	3	Sort	Sort	ORDER BY:([DB].[dbo].[test_a2].[processed] DESC, [DB].[dbo].[test_a2].[ID] ASC)	NULL	49	1897,646	529,5381	76	1,360734	[DB].[dbo].[test_a2].[ID], [DB].[dbo].[test_a2].[summ], [DB].[dbo].[test_a2].[name], [DB].[dbo].[test_a2].[processed]	NULL	PLAN_ROW	0	1
                 |--Index Scan(OBJECT:([DB].[dbo].[test_a2].[idx_test_a_processed]))	1	7	6	Index Scan	Index Scan	OBJECT:([DB].[dbo].[test_a2].[idx_test_a_processed])	[DB].[dbo].[test_a2].[ID], [DB].[dbo].[test_a2].[summ], [DB].[dbo].[test_a2].[name], [DB].[dbo].[test_a2].[processed]	1,33123E+07	71,98164	14,64368	76	1,360734	[DB].[dbo].[test_a2].[ID], [DB].[dbo].[test_a2].[summ], [DB].[dbo].[test_a2].[name], [DB].[dbo].[test_a2].[processed]	NULL	PLAN_ROW	0	1

SELECT TOP 50 name, id, processed, summ from dbo.test_all2
ORDER BY processed ASC	2	8	0	NULL	NULL	2	NULL	50	NULL	NULL	NULL	1,340439	NULL	NULL	SELECT	0	NULL
  |--Top(TOP EXPRESSION:((50)))	2	9	8	Top	Top	TOP EXPRESSION:((50))	NULL	50	0	5E-06	76	1,340439	[Union1006], [Union1007], [Union1008], [Union1009]	NULL	PLAN_ROW	0	1
       |--Merge Join(Concatenation)	2	10	9	Merge Join	Concatenation	NULL	[Union1009] = ([DB].[dbo].[test_b2].[processed], [DB].[dbo].[test_a2].[processed]), [Union1006] = ([DB].[dbo].[test_b2].[ID], [DB].[dbo].[test_a2].[ID]), [Union1007] = ([DB].[dbo].[test_b2].[summ], [DB].[dbo].[test_a2].[summ]), [Union1008] = ([DB].[dbo].[test_b2].[name], [DB].[dbo].[test_a2].[name])	50	0	1,336834	76	1,340434	[Union1009], [Union1006], [Union1007], [Union1008]	NULL	PLAN_ROW	0	1
            |--Index Scan(OBJECT:([DB].[dbo].[test_b2].[idx_test_b_processed]), ORDERED FORWARD)	2	11	10	Index Scan	Index Scan	OBJECT:([DB].[dbo].[test_b2].[idx_test_b_processed]), ORDERED FORWARD	[DB].[dbo].[test_b2].[ID], [DB].[dbo].[test_b2].[summ], [DB].[dbo].[test_b2].[name], [DB].[dbo].[test_b2].[processed]	1	0,003125	0,0001581	76	0,0032831	[DB].[dbo].[test_b2].[ID], [DB].[dbo].[test_b2].[summ], [DB].[dbo].[test_b2].[name], [DB].[dbo].[test_b2].[processed]	NULL	PLAN_ROW	0	1
            |--Index Scan(OBJECT:([DB].[dbo].[test_a2].[idx_test_a_processed]), ORDERED FORWARD)	2	12	10	Index Scan	Index Scan	OBJECT:([DB].[dbo].[test_a2].[idx_test_a_processed]), ORDERED FORWARD	[DB].[dbo].[test_a2].[ID], [DB].[dbo].[test_a2].[summ], [DB].[dbo].[test_a2].[name], [DB].[dbo].[test_a2].[processed]	49	71,98164	14,64368	76	0,003595432	[DB].[dbo].[test_a2].[ID], [DB].[dbo].[test_a2].[summ], [DB].[dbo].[test_a2].[name], [DB].[dbo].[test_a2].[processed]	NULL	PLAN_ROW	0	1




Уже лучше, за тем исключением, что первый запрос отрабатывает 15 секунд, а второй доли секунд.
А еще огромный минус в том, что полей в реальной таблице, а не тестовой гораздо больше.

К сообщению приложен файл (plan2.xml - 43Kb) cкачать
16 апр 13, 11:37    [14186002]     Ответить | Цитировать Сообщить модератору
 Re: В представлении оптимизатор не видит индексов  [new]
_ч_
Member

Откуда:
Сообщений: 1440
План картинкой, кому лень скачивать xml.


Теперь версия сервера
автор
Microsoft SQL Server 2012 (SP1) - 11.0.3000.0 (X64)
Oct 19 2012 13:38:57
Copyright (c) Microsoft Corporation
Enterprise Edition (64-bit) on Windows NT 6.1 <X64> (Build 7601: Service Pack 1)


К сообщению приложен файл. Размер - 35Kb
16 апр 13, 11:40    [14186023]     Ответить | Цитировать Сообщить модератору
 Re: В представлении оптимизатор не видит индексов  [new]
Мистер Хенки
Member

Откуда: канализация
Сообщений: 6615
_ч_
Мистер Хенки,

воспользовался Вашим советом.


Уже лучше, за тем исключением, что первый запрос отрабатывает 15 секунд, а второй доли секунд.
А еще огромный минус в том, что полей в реальной таблице, а не тестовой гораздо больше.


Тогда возвращайтесь к первоначальному варианту и указывайте кластерный ключ явно при сортировке
SELECT TOP 50 * FROM dbo.test_all
ORDER BY processed DESC,ID asc


SELECT TOP 50 * from dbo.test_all order by processed ASC,ID desc
16 апр 13, 12:16    [14186280]     Ответить | Цитировать Сообщить модератору
 Re: В представлении оптимизатор не видит индексов  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34696
_ч_
Glory,

у меня тоже возникли такие же сомнения.
И что же теперь делать? Не использовать union all во вьюхе?


Да вообще лучше View не использовать.
На кой оно тебе ?
16 апр 13, 13:21    [14186732]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
Все форумы / Microsoft SQL Server Ответить