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

Откуда:
Сообщений: 1197
Может ли:

1. План запроса на одних и тех же данных поиска меняться в зависимости от загрузки сервера? Т.е. Например 5 минут назад симантек что-то сканировал - был один план запроса, а сейчас другой
2. Дефрвгментация диска влиять на скорость селектов?
3. Раздувшийся лог транзакций влиять на производительность? Места на диске процентов 20
13 апр 15, 18:21    [17509382]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос по производительности  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31486
relief
Может ли:

1. План запроса на одних и тех же данных поиска меняться в зависимости от загрузки сервера? Т.е. Например 5 минут назад симантек что-то сканировал - был один план запроса, а сейчас другой
2. Дефрвгментация диска влиять на скорость селектов?
3. Раздувшийся лог транзакций влиять на производительность? Места на диске процентов 20
1. Нет. План может меняться от изменения параметров запроса, и от изменения статистики.
2. Да (точнее, фрагментация файлов данных и лога сиквела), но влияние не особо сильное.
3. Нет.
13 апр 15, 19:17    [17509562]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос по производительности  [new]
SQL2008
Member

Откуда: Москва
Сообщений: 4312
relief
... симантек что-то сканировал

У вас антивирус сканирует файлы баз данных?
13 апр 15, 19:32    [17509590]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос по производительности  [new]
Mind
Member

Откуда: Лучший город на Земле
Сообщений: 2322
SQL2008
relief
... симантек что-то сканировал

У вас антивирус сканирует файлы баз данных?
Ну а вдруг туда вирус кто-то записал в varbinary поле?
13 апр 15, 23:49    [17510321]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос по производительности  [new]
relief
Member

Откуда:
Сообщений: 1197
alexeyvg
relief
Может ли:

1. План запроса на одних и тех же данных поиска меняться в зависимости от загрузки сервера? Т.е. Например 5 минут назад симантек что-то сканировал - был один план запроса, а сейчас другой
2. Дефрвгментация диска влиять на скорость селектов?
3. Раздувшийся лог транзакций влиять на производительность? Места на диске процентов 20
1. Нет. План может меняться от изменения параметров запроса, и от изменения статистики.
2. Да (точнее, фрагментация файлов данных и лога сиквела), но влияние не особо сильное.
3. Нет.


смотрите, надо понять почему запрос работал на одних и тех же данных быстро, а потом стал медленно.
скажите профайлер, но как мне сравнить с тем когда работало быстро?
т.е. сейчас например селект из таблицы с 200 млн записей и джойном другой таблицы в 200 тыс работает 6 минут.
что посоветуете, чтобы найти почему работало быстро, а стало медленней?
14 апр 15, 08:22    [17510803]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос по производительности  [new]
Glory
Member

Откуда:
Сообщений: 104760
relief
смотрите, надо понять почему запрос работал на одних и тех же данных быстро, а потом стал медленно.

Например, ожидал заблокированные объекты
14 апр 15, 08:23    [17510809]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос по производительности  [new]
relief
Member

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

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

а как это можно протрейсить? сделать трейс в профайлере на блокировки (запрос, получение, освобождение)?
14 апр 15, 08:44    [17510868]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос по производительности  [new]
Glory
Member

Откуда:
Сообщений: 104760
DBCC SQLPERF("sys.dm_os_wait_stats")
14 апр 15, 09:26    [17511063]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос по производительности  [new]
relief
Member

Откуда:
Сообщений: 1197
Glory
DBCC SQLPERF("sys.dm_os_wait_stats")


а для sql 2005 есть аналог?
14 апр 15, 09:56    [17511216]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос по производительности  [new]
Glory
Member

Откуда:
Сообщений: 104760
dbcc sqlperf(waitstats)
14 апр 15, 09:58    [17511221]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос по производительности  [new]
relief
Member

Откуда:
Сообщений: 1197
Glory
dbcc sqlperf(waitstats)


сделал много тестов на одних тех же данных и условиях и нашел интересную вещь.

джойн большой таблицы на табличную переменную (80 тыс. строк) работает быстрей джойна с временной таблицей c теми же данными, причем в 5 раз.
пробовал запускать в разных очередностях: до, после, вовремя. но всегда табличная переменная работает не более 2 минут, а времменная таблица не менее 5 минут.

и там и там есть индексы. планы получаются разные, это да, но почему такая разница? ведь оба объекта в tempdb.
планы разные, в аттаче оба.
почему оптимизатор разные планы использует, в чем причина тормозов может быть и что делать?

К сообщению приложен файл (plans.zip.zip - 9Kb) cкачать
14 апр 15, 14:19    [17512958]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос по производительности  [new]
Glory
Member

Откуда:
Сообщений: 104760
relief
и там и там есть индексы

Это вы про табличную переменную и временную таблицу ?
14 апр 15, 14:21    [17512975]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос по производительности  [new]
relief
Member

Откуда:
Сообщений: 1197
Glory
relief
и там и там есть индексы

Это вы про табличную переменную и временную таблицу ?


да.
в табличной переменной UNIQUE NONCLUSTERED
во временной таблице тоже самое и по тому же полю
14 апр 15, 14:25    [17513002]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос по производительности  [new]
o-o
Guest
relief
К сообщению приложен файл (plans.zip.zip - 9Kb)

а что за формат у файлов?
это не XML...
14 апр 15, 14:41    [17513107]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос по производительности  [new]
relief
Member

Откуда:
Сообщений: 1197
o-o
relief
К сообщению приложен файл (plans.zip.zip - 9Kb)

а что за формат у файлов?
это не XML...


анонимайзером прошел sql sentry plan explorer
14 апр 15, 14:43    [17513116]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос по производительности  [new]
relief
Member

Откуда:
Сообщений: 1197
o-o
relief
К сообщению приложен файл (plans.zip.zip - 9Kb)

а что за формат у файлов?
это не XML...


sorry
не в том формате сохранил

К сообщению приложен файл (tempTable_Anonymized.zip - 5Kb) cкачать
14 апр 15, 14:46    [17513143]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос по производительности  [new]
o-o
Guest
relief
почему такая разница? ведь оба объекта в tempdb.

дело не в tempdb, а в оценке размеров участников соединения и размеров результата.

когда вы свою Object3 в 93 млн строк соединяете со временной таблицей,
он выбирает hash join, тк считает, что слишком много строк для nested loops
(и на выходе ожидает 1,5 млн, т.е. промахивается с оценкой раз в 20)

а когда табличная переменная, он ее оценивает в 1 строку и выбирает nested loops,
типа во внешней таблице всего 1 строка, во внутренней есть подходящий индекс,
на выходе ожидает примерно 130.000 строк (а на деле там 86.000, т.е. примерно угадал)
14 апр 15, 16:27    [17513975]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос по производительности  [new]
relief
Member

Откуда:
Сообщений: 1197
o-o
relief
почему такая разница? ведь оба объекта в tempdb.

дело не в tempdb, а в оценке размеров участников соединения и размеров результата.

когда вы свою Object3 в 93 млн строк соединяете со временной таблицей,
он выбирает hash join, тк считает, что слишком много строк для nested loops
(и на выходе ожидает 1,5 млн, т.е. промахивается с оценкой раз в 20)

а когда табличная переменная, он ее оценивает в 1 строку и выбирает nested loops,
типа во внешней таблице всего 1 строка, во внутренней есть подходящий индекс,
на выходе ожидает примерно 130.000 строк (а на деле там 86.000, т.е. примерно угадал)


спасибо большое!

Если вас не затруднит, не могли бы немного пояснить с чем связано, что в случае временных таблиц такой промах в оценке? Статистика?
Что надо делать?
14 апр 15, 16:49    [17514126]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос по производительности  [new]
o-o
Guest
relief,

со временной таблицей все хорошо,
это переменную неправильно оценили, хотя и получилось удачно,
он повелся на 1 строку :)

у вас видимо кластерный как раз по полям Column7, Column30, к-ые в
WHERE
Object2.Column7 BETWEEN ? AND ?
AND Object2.Column30 = ?
и он считает, что тут можно интервал просканировать.
а так решает наверное потому, что другого подходящего индекса он не видит,
а я тем более, вы же не выложили скрипты ни таблицы, ни индексов.
14 апр 15, 17:22    [17514269]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос по производительности  [new]
loik
Guest
[quot o-o]relief,

со временной таблицей все хорошо,
это переменную неправильно оценили, хотя и получилось удачно,
он повелся на 1 строку
[/SRC] :)

у вас видимо кластерный как раз по полям Column7, Column30, к-ые в 
WHERE  
	Object2.Column7 BETWEEN ? AND ?	
	AND Object2.Column30 = ?   
и он считает, что тут можно интервал просканировать.
а так решает наверное потому, что другого подходящего индекса он не видит,
а я тем более, вы же не выложили скрипты ни таблицы, ни индексов.[/quot]

вот основная таблица с индексами по ней.
Column7 - это SaleDate  
Column30 - это carSaleCountryId
собственно кластерный индекс по этим полям.

[src]create table Sales
(  
   carWin        -- не уникален в таблице, т.к. одна машина может перепродаваться  
  ,carSaleCountryId
  ,carArticul
  ,SaleDate  
  ,ManagerId
  ,SellerShopCode
  ,BuyerShopCode
  ,BuyerName
  ,SaleToForeignCitizen
  ,BuyerAddress
  ,CreateUserId
  ,CreateDate  
  ,FormattedCarWin   --иногда win в поле carWin идет со служебными символами. В данном поле хранится отформатированное значение
)

CREATE CLUSTERED INDEX IX_CLUSTER ON Sales
(
	SaleDate ASC,
	carSaleCountryId ASC
)WITH (PAD_INDEX = ON, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON, FILLFACTOR = 80) ON [PRIMARY]
GO

CREATE NONCLUSTERED INDEX [IDX_1] ON Sales
(
	SaleDate ASC,
	carSaleCountryId ASC,
	carWin ASC,
	SaleToForeignCitizen ASC,
	CreateDate ASC,
	carArticul ASC
)
INCLUDE ( 	SellerShopCode,
	ManagerId,
	BuyerShopCode,
	CreateUserId,
	BuyerName,
	BuyerAddress) 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 [PRIMARY]
GO

ALTER TABLE Sales ADD  CONSTRAINT [PK_PRIMARY] PRIMARY KEY NONCLUSTERED 
(
	carSaleCountryId ASC,
	SaleDate ASC,
	SellerShopCode ASC,
	ManagerId ASC,
	carArticul ASC,
	SaleToForeignCitizen ASC,
	SellerShopCode ASC,
	BuyerShopCode ASC,
	carWin ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
GO

CREATE NONCLUSTERED INDEX [IDX_FormattedCarWin] ON Sales
(
	FormattedCarWin ASC
)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 [PRIMARY]
GO


скрипт по созданию временной таблицы такой. во временную таблицу вставляются форматированные win и потом идет джойн именно по полю FormattedCarWin в таблице Sales

CREATE TABLE #TmpWins
(FormattedCarWin    VARCHAR(20) COLLATE SQL_Latin1_General_CP1_CI_AS)
					
INSERT #TmpWins
SELECT FormattedCarWin   
FROM Temp 
 					
CREATE INDEX IX ON #TmpWins(FormattedCarWin) 
15 апр 15, 09:51    [17516617]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос по производительности  [new]
loik
Guest
удалил COLLATE SQL_Latin1_General_CP1_CI_AS в данном месте и временные таблицы заработали также как и табличные переменные, и план такой же стал как у табличной переменной

CREATE TABLE #TmpWins (FormattedCarWin    VARCHAR(20) COLLATE SQL_Latin1_General_CP1_CI_AS)


COLLATE на самом деле одинаковые у полей в джойне, поэтому и удалил (просто в некоторых местах разные).
но почему из-за этого другой план, ведь коллейшны одинаковые?

и можно как-то ускорить текущий запрос?

Спасибо
15 апр 15, 10:05    [17516685]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос по производительности  [new]
o-o
Guest
теперь еще запрос покажите,
или как еще можно догадаться, у вас индекс покрывающий или нет, если в запросе анонимированные поля?
и по какому полю соединение.
(а лучше, запрос + план с соответствующими именами, чтобы не искать, что есть что)
хотя если все заработало, то и ладно,
но на будущее:
вот где в вашем вчера приведенном плане создание временной таблицы?
там же сразу insert.
как можно догадаться, что там был COLLATE SQL_Latin1_General_CP1_CI_AS?
и про коллэйшены мне странно, что если они такие "совпадающие",
то с чего вдруг без явного указания COLLATE SQL_Latin1_General_CP1_CI_AS при создании таблицы что-то поменялось,
поэтому покажите результат:
select DATABASEPROPERTYEX('tempdb', 'collation') as tempdb_coll,
       DATABASEPROPERTYEX('your_db', 'collation') as db_coll,
       collation_name as column_coll
from sys.columns
where object_id = object_id('dbo.Sales') and name = 'FormattedCarWin'              
15 апр 15, 10:38    [17516873]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос по производительности  [new]
loik
Guest
o-o
теперь еще запрос покажите,
или как еще можно догадаться, у вас индекс покрывающий или нет, если в запросе анонимированные поля?
и по какому полю соединение.
(а лучше, запрос + план с соответствующими именами, чтобы не искать, что есть что)
хотя если все заработало, то и ладно,
но на будущее:
вот где в вашем вчера приведенном плане создание временной таблицы?
там же сразу insert.
как можно догадаться, что там был COLLATE SQL_Latin1_General_CP1_CI_AS?
и про коллэйшены мне странно, что если они такие "совпадающие",
то с чего вдруг без явного указания COLLATE SQL_Latin1_General_CP1_CI_AS при создании таблицы что-то поменялось,
поэтому покажите результат:
select DATABASEPROPERTYEX('tempdb', 'collation') as tempdb_coll,
       DATABASEPROPERTYEX('your_db', 'collation') as db_coll,
       collation_name as column_coll
from sys.columns
where object_id = object_id('dbo.Sales') and name = 'FormattedCarWin'              


вот что по коллейшну
tempdb_coll    Latin1_General_CI_AS	
db_coll	    SQL_Latin1_General_CP1_CI_AS	
column_coll    SQL_Latin1_General_CP1_CI_AS


вот скрипт создания временной таблицы и сам селект

CREATE TABLE #TmpWins
(FormattedCarWin    VARCHAR(20) COLLATE SQL_Latin1_General_CP1_CI_AS)
					
INSERT #TmpWins
SELECT FormattedCarWin   
FROM Temp 
 					
CREATE INDEX IX ON #TmpWins(FormattedCarWin) 	

SELECT [a].[carWin]  					  
			,[a].[carArticul]					
			,[a].[Survey_YMD]		
			,[a].[ManagerId]   				
			,[a].[SellerShopCode] 
			,[a].[BuyerShopCode] 		
			,[a].[BuyerName] 				
			,[a].[BuyerAddress]  
			,[a].[CreateUserId]  
			,[a].[CreateDate] 			
		FROM  Sales a with(nolock)
			JOIN #TmpWins s
			ON [a].[FormattedCarWin] COLLATE SQL_Latin1_General_CP1_CI_AS = s.FormattedCarWin					   				    
		WHERE [a].[SaleDate] BETWEEN '2005-01-01' AND '2015-01-01'	
			AND  a.carSaleCountryId = 5  
15 апр 15, 11:36    [17517300]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос по производительности  [new]
o-o
Guest
loik
tempdb_coll Latin1_General_CI_AS
db_coll SQL_Latin1_General_CP1_CI_AS
column_coll SQL_Latin1_General_CP1_CI_AS

ну так видите же, что как раз не совпадает коллэйшен столбца основной таблицы (SQL_Latin1_General_CP1_CI_AS)
с коллэйшеном tempdb -- Latin1_General_CI_AS -- (коллэйшеном столбца временной таблицы, создаваемом без явного COLLATE).
а коллэйшен табличной переменной совпадает с коллэйшеном базы.
когда у вас поля различаются коллэйшеном, вы исключаете индексы по этим полям для того,
кому в соединении указываете COLLATE...

только я уже ничего не понимаю, кому вы что сменили,
если:
CREATE TABLE #TmpWins
(FormattedCarWin    VARCHAR(20) COLLATE SQL_Latin1_General_CP1_CI_AS)

+ column_coll   SQL_Latin1_General_CP1_CI_AS
					

то зачем в запросе
ON [a].[FormattedCarWin] COLLATE SQL_Latin1_General_CP1_CI_AS = s.FormattedCarWin

???
15 апр 15, 12:05    [17517466]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос по производительности  [new]
loik
Guest
o-o
только я уже ничего не понимаю, кому вы что сменили,
если:
CREATE TABLE #TmpWins
(FormattedCarWin    VARCHAR(20) COLLATE SQL_Latin1_General_CP1_CI_AS)

+ column_coll   SQL_Latin1_General_CP1_CI_AS
					

то зачем в запросе
ON [a].[FormattedCarWin] COLLATE SQL_Latin1_General_CP1_CI_AS = s.FormattedCarWin

???


я делал тест в студии, где была выбрана база с коллейшном SQL_Latin1_General_CP1_CI_AS. Выбрал tempdb. Скрипт стал таким

use tempdb

CREATE TABLE #TmpWins
(FormattedCarWin    VARCHAR(20) COLLATE SQL_Latin1_General_CP1_CI_AS)
					
INSERT #TmpWins
SELECT FormattedCarWin   
FROM Temp 
 					
CREATE INDEX IX ON #TmpWins(FormattedCarWin) 	

SELECT [a].[carWin]  					  
			,[a].[carArticul]					
			,[a].[Survey_YMD]		
			,[a].[ManagerId]   				
			,[a].[SellerShopCode] 
			,[a].[BuyerShopCode] 		
			,[a].[BuyerName] 				
			,[a].[BuyerAddress]  
			,[a].[CreateUserId]  
			,[a].[CreateDate] 			
		FROM  Sales a with(nolock)
			JOIN #TmpWins s
			ON [a].[FormattedCarWin] = s.FormattedCarWin					   				    
		WHERE [a].[SaleDate] BETWEEN '2005-01-01' AND '2015-01-01'	
			AND  a.carSaleCountryId = 5  


но только этот запрос не использует индекс, и работает медленно, хотя я ожидал, раз коллейшны в #TmpWins для FormattedCarWin и FormattedCarWin в Sales совпадают, то индексы будут использованы.
я ведь при создании временной таблицы указал коллейшн, как мне нужен, а в Sales, он такой же как во временной таблице
Что ему не нравится?
15 апр 15, 13:39    [17518247]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос по производительности  [new]
o-o
Guest
loik,

давайте план к этому запросу
15 апр 15, 13:48    [17518327]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос по производительности  [new]
loik
Guest
o-o
loik,

давайте план к этому запросу


приложил

К сообщению приложен файл (select_Anonymized - Copy.sqlplan - 19Kb) cкачать
15 апр 15, 14:25    [17518590]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос по производительности  [new]
o-o
Guest
с этим планом ок,
а можно снова план с переменной посмотреть,
и чтобы было подписано,
какие столбцы из какого индекса берутся.
15 апр 15, 17:12    [17519756]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос по производительности  [new]
loik
Guest
o-o
с этим планом ок,
а можно снова план с переменной посмотреть,
и чтобы было подписано,
какие столбцы из какого индекса берутся.


так нормально?

К сообщению приложен файл (selectTableVar_Anonymized.sqlplan - 17Kb) cкачать
15 апр 15, 17:48    [17519927]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос по производительности  [new]
loik
Guest
loik
o-o
с этим планом ок,
а можно снова план с переменной посмотреть,
и чтобы было подписано,
какие столбцы из какого индекса берутся.


так нормально?


o-o сможете помочь?
16 апр 15, 11:50    [17522630]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос по производительности  [new]
o-o
Guest
loik,
давайте ему насильно индекс пропишем:
SELECT [a].[carWin]  					  
			,[a].[carArticul]					
			,[a].[Survey_YMD]		
			,[a].[ManagerId]   				
			,[a].[SellerShopCode] 
			,[a].[BuyerShopCode] 		
			,[a].[BuyerName] 				
			,[a].[BuyerAddress]  
			,[a].[CreateUserId]  
			,[a].[CreateDate] 			
		FROM  Sales a with(nolock, index(IDX_FormattedCarWin))
			JOIN #TmpWins s
			ON [a].[FormattedCarWin] 				   				    
		WHERE [a].[SaleDate] BETWEEN '2005-01-01' AND '2015-01-01'	
			AND  a.carSaleCountryId = 5

вы попробуйте так, доложите о результатах, я пока читаю про статистику, может, ему надо ее так подсобрать,
чтобы сам догадался
16 апр 15, 12:10    [17522832]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос по производительности  [new]
loik
Guest
o-o
loik,
давайте ему насильно индекс пропишем:
SELECT [a].[carWin]  					  
			,[a].[carArticul]					
			,[a].[Survey_YMD]		
			,[a].[ManagerId]   				
			,[a].[SellerShopCode] 
			,[a].[BuyerShopCode] 		
			,[a].[BuyerName] 				
			,[a].[BuyerAddress]  
			,[a].[CreateUserId]  
			,[a].[CreateDate] 			
		FROM  Sales a with(nolock, index(IDX_FormattedCarWin))
			JOIN #TmpWins s
			ON [a].[FormattedCarWin] 				   				    
		WHERE [a].[SaleDate] BETWEEN '2005-01-01' AND '2015-01-01'	
			AND  a.carSaleCountryId = 5

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


индекс IDX_FormattedCarWin применился и по скорости нормально, как с табличной переменной.
но по временной таблице все равно применился TableScan. В случае с табличными переменными применился IndexSeek к табличной переменной, хотя индекс на временную таблицу создал
16 апр 15, 13:30    [17523607]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос по производительности  [new]
o-o
Guest
loik,

в случае с табличной переменной тоже скан,
посмотрите свой последний план.
16 апр 15, 13:44    [17523750]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос по производительности  [new]
loik
Guest
o-o
loik,

в случае с табличной переменной тоже скан,
посмотрите свой последний план.


да. просто с табличной переменной был индекс скан,
а с временной таблицей table скан
16 апр 15, 13:55    [17523849]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос по производительности  [new]
o-o
Guest
loik,

скан там будет по-любому, мы же хотели получить Nested Loops, мы его и получили, временная таблица или переменная все равно будет "внешней", ее всю просматривать.
в случае переменной вы создали кластерный индекс, поэтому индекс скан, в случае таблицы вы создали некластерный индекс, если использовали просто create index, тк по умолчанию создается некластерный, поэтому идет скан таблицы, она же в результате меньше индекса, он тут и не нужен, мы же хотели, чтобы он подцеплял индекс на основной таблице, а не хэши считал на 93 млн. строк.

вроде даже и collate ни при чем, вы же им приводили к нужному строки во временной таблице, а не наоборот
16 апр 15, 15:11    [17524673]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос по производительности  [new]
loik
Guest
o-o
loik,

скан там будет по-любому, мы же хотели получить Nested Loops, мы его и получили, временная таблица или переменная все равно будет "внешней", ее всю просматривать.
в случае переменной вы создали кластерный индекс, поэтому индекс скан, в случае таблицы вы создали некластерный индекс, если использовали просто create index, тк по умолчанию создается некластерный, поэтому идет скан таблицы, она же в результате меньше индекса, он тут и не нужен, мы же хотели, чтобы он подцеплял индекс на основной таблице, а не хэши считал на 93 млн. строк.

вроде даже и collate ни при чем, вы же им приводили к нужному строки во временной таблице, а не наоборот


т.е. дело в статистике, но что именно не так непонятно?
16 апр 15, 15:19    [17524729]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: 1 2      [все]
Все форумы / Microsoft SQL Server Ответить