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

Откуда:
Сообщений: 28
Есть в базе две таблицы:
+ MetaData 114,5 тыс.строк
CREATE TABLE [dbo].[MetaData](
	[id] [numeric](18, 0) IDENTITY(1,1) NOT FOR REPLICATION NOT NULL,
	[DBUUID] [char](36) NOT NULL,
	[CodeTypeObject] [smallint] NOT NULL,
	[NameObject] [nchar](200) NOT NULL,
	[DescrObject] [nchar](300) NOT NULL,
	[CodeTableObject] [int] NOT NULL,
	[CodeTableObject36] [char](9) NOT NULL,
	[CodeTypeProps] [smallint] NOT NULL,
	[NameProps] [nchar](200) NOT NULL,
	[DescrProps] [nchar](300) NOT NULL,
	[CodeProps] [int] NOT NULL,
	[CodeProps36] [char](9) NOT NULL,
 CONSTRAINT [PK_MetaData] 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 [PRIMARY]
) ON [PRIMARY]
GO
SET ANSI_PADDING OFF
GO
ALTER TABLE [dbo].[MetaData] ADD  CONSTRAINT [DF_MetaData_DescrObject]  DEFAULT ('') FOR [DescrObject]
GO
ALTER TABLE [dbo].[MetaData] ADD  CONSTRAINT [DF_MetaData_CodeTableObject36]  DEFAULT ('') FOR [CodeTableObject36]
GO
ALTER TABLE [dbo].[MetaData] ADD  CONSTRAINT [DF_MetaData_DescrProps]  DEFAULT ('') FOR [DescrProps]
GO
ALTER TABLE [dbo].[MetaData] ADD  CONSTRAINT [DF_MetaData_CodeProps36]  DEFAULT ('') FOR [CodeProps36]
GO

+ MetaDataAcc 5,8 тыс. строк
CREATE TABLE [dbo].[MetaDataAcc](
	[ROW_ID] [numeric](18, 0) IDENTITY(1,1) NOT FOR REPLICATION NOT NULL,
	[DBUUID] [char](36) NOT NULL,
	[ID] [char](9) NOT NULL,
	[PLANID] [int] NOT NULL,
	[PLANIM] [nchar](80) NOT NULL,
	[SCHKOD] [char](8) NOT NULL,
	[SCHIM] [char](80) NOT NULL,
	[SCHV] [bit] NOT NULL,
	[SCHKOL] [bit] NOT NULL,
	[SCHSINGLE] [bit] NOT NULL,
	[ISFOLDER] [bit] NOT NULL,
	[ISMARK] [bit] NOT NULL,
	[LEVEL_] [smallint] NOT NULL,
	[MDID] [int] NOT NULL,
	[ACTIVE] [tinyint] NOT NULL,
	[SC0] [int] NOT NULL,
	[OSC0] [tinyint] NOT NULL,
	[FSC0] [tinyint] NOT NULL,
	[SC1] [int] NOT NULL,
	[OSC1] [tinyint] NOT NULL,
	[FSC1] [tinyint] NOT NULL,
	[SC2] [int] NOT NULL,
	[OSC2] [tinyint] NOT NULL,
	[FSC2] [tinyint] NOT NULL,
 CONSTRAINT [PK_MetaDataAcc] PRIMARY KEY CLUSTERED 
(
	[ROW_ID] ASC
)WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON) ON [PRIMARY]
) ON [PRIMARY]
GO
SET ANSI_PADDING OFF
GO


И есть вот такой запрос:
SELECT MDAcc.[PLANID],MDAcc.[PLANIM],MDAcc.[ID],MDAcc.[SCHKOD],MDAcc.[SCHIM],MDAcc.[SCHV],MDAcc.[SCHKOL]
      ,MDAcc.[SCHSINGLE],MDAcc.[ISFOLDER],MDAcc.[ISMARK],MDAcc.[LEVEL_],MDAcc.[MDID],MDAcc.[ACTIVE]
      ,MDAcc.[SC0],MDAcc.[OSC0],MDAcc.[FSC0]
      ,IsNULL(MD0.NameObject,'') SC0Name,IsNULL(MD0.DescrObject,'') SC0Descr
      ,IsNULL(MD0.NameProps,'') SC0_Type,IsNULL(MD0.DescrProps,'') SC0_Kind
      ,IsNULL(MD0.CodeProps,0) SC0_TypeCode,IsNULL(MD0.CodeProps36,'') SC0_TypeCode36
      ,MDAcc.[SC1],MDAcc.[OSC1],MDAcc.[FSC1]
      ,IsNULL(MD1.NameObject,'') SC1Name,IsNULL(MD1.DescrObject,'') SC1Descr
      ,IsNULL(MD1.NameProps,'') SC1_Type,IsNULL(MD1.DescrProps,'') SC1_Kind
      ,IsNULL(MD1.CodeProps,0) SC1_TypeCode,IsNULL(MD1.CodeProps36,'') SC1_TypeCode36
      ,MDAcc.[SC2],MDAcc.[OSC2],MDAcc.[FSC2]
      ,IsNULL(MD2.NameObject,'') SC2Name,IsNULL(MD2.DescrObject,'') SC2Descr
      ,IsNULL(MD2.NameProps,'') SC2_Type,IsNULL(MD2.DescrProps,'') SC2_Kind
      ,IsNULL(MD2.CodeProps,0) SC2_TypeCode,IsNULL(MD2.CodeProps36,'') SC2_TypeCode36
FROM [MetaDataAcc] MDAcc
	LEFT JOIN [MetaData] MD0 ON (MDAcc.[SC0]>0)AND(MDAcc.[SC0] = MD0.[CodeTableObject]) AND (MDAcc.[DBUUID] = MD0.[DBUUID])
	LEFT JOIN [MetaData] MD1 ON (MDAcc.[SC1]>0)AND(MDAcc.[SC1] = MD1.[CodeTableObject]) AND (MDAcc.[DBUUID] = MD1.[DBUUID])
	LEFT JOIN [MetaData] MD2 ON (MDAcc.[SC2]>0)AND(MDAcc.[SC2] = MD2.[CodeTableObject]) AND (MDAcc.[DBUUID] = MD2.[DBUUID])
WHERE (MDAcc.[DBUUID] = @P1) AND (MDAcc.[PLANID] = @P2)
ORDER BY MDAcc.[PLANIM], MDAcc.[SCHKOD]


Недавно в данные таблицы были добавлены новые записи. Представленный запрос с параметрами, которые относятся к старым записям, выполняется менее секунды. Если указать параметры, которые относятся к недавно добавленным данным, то время выполнения вырастает до 30-35 секунд. Тормоза явно из-за обращения "LEFT JOIN [MetaData]...". Я могу переделать запрос и делать LEFT JOIN к временной таблице, которая будет предварительно сформирована из [MetaData] с отбором по полю DBUUID. Но может есть другие варианты решения?
Подскажите, пожалуйста, куда копать: индексы, статистика или что-то еще?

+ Microsoft SQL Server
Microsoft SQL Server Management Studio 10.50.1600.1
Клиентские средства служб Microsoft Analysis Services 10.50.1600.1
Компоненты доступа к данным (MDAC) 3.86.3959
Microsoft MSXML 3.0 5.0 6.0
Microsoft Internet Explorer 8.0.7601.17514
Microsoft .NET Framework 2.0.50727.5420
Операционная система 6.1.7601
19 фев 17, 18:31    [20226328]     Ответить | Цитировать Сообщить модератору
 Re: Тормозит запрос  [new]
Bator
Member

Откуда: Порт пяти морей
Сообщений: 439
Lokli, нет данных про индексы.
если данных так мало и нарастание медленное, то кластерные индексы по двум полям DBUUID CodeTableObject/PLANID радикально изменят результат.
19 фев 17, 22:32    [20226940]     Ответить | Цитировать Сообщить модератору
 Re: Тормозит запрос  [new]
Idol_111
Member

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

ну статистику я надеюсь вы наверное уже обновили с полным сканированием?
20 фев 17, 04:10    [20227151]     Ответить | Цитировать Сообщить модератору
 Re: Тормозит запрос  [new]
Lokli
Member

Откуда:
Сообщений: 28
Извините, забыл про индексы.
В обоих таблицах присутствует кластеризованный индекс по id.
И в таблице MetaData есть еще такие индексы:
+
CREATE UNIQUE NONCLUSTERED INDEX [DBUUID_Object_Props] ON [dbo].[MetaData] 
(
	[DBUUID] ASC,
	[NameObject] ASC,
	[CodeTableObject] ASC,
	[CodeTypeProps] ASC,
	[NameProps] ASC,
	[CodeProps] ASC
)WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON) ON [PRIMARY]
GO
CREATE NONCLUSTERED INDEX [DBUUID_Object] ON [dbo].[MetaData] 
(
	[DBUUID] ASC,
	[CodeTypeObject] ASC,
	[NameObject] ASC,
	[CodeTableObject] ASC
)WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON) ON [PRIMARY]
20 фев 17, 10:06    [20227520]     Ответить | Цитировать Сообщить модератору
 Re: Тормозит запрос  [new]
Кесарь
Member

Откуда:
Сообщений: 677
Lokli, выше уже написали: обновите статистику с полным сканированием. Должно помочь.
20 фев 17, 10:09    [20227541]     Ответить | Цитировать Сообщить модератору
 Re: Тормозит запрос  [new]
Lokli
Member

Откуда:
Сообщений: 28
Перестроил индексы по таблице MetaData. Обновил статистику по данным индексам. Запрос стал формироваться быстрее: 13 секунд, вместо 34. Но это всё равно много.
Посмотрел фактический план выполнения по запроса (наверно с этого и надо было начинать). В нём видно, что 98% времени уходит на поиск id элементов таблицы MetaData. Так же, в плане выполнения выползла рекомендация на создание дополнительного индекса:
+
/*
Обработчик запросов считает, что реализация следующего индекса может сократить стоимость запроса на 35.6153%.
*/

/*
GO
CREATE NONCLUSTERED INDEX [<Name of Missing Index, sysname,>]
ON [dbo].[MetaData] ([DBUUID])
INCLUDE ([NameObject],[DescrObject],[CodeTableObject],[NameProps],[DescrProps],[CodeProps],[CodeProps36])
GO
*/


Спасибо за советы. Пошел курить MSDN про индексы.

P.S.: если честно, не понимаю почему один и тот же запрос при разных параметрах, возвращая сопоставимые объёмы информации (503 и 409 строк), выполняется за столь разные промежутки времени? Если это влияет статистика, то надо подождать пока она накопится и тогда "новые" данные станут "старыми" и запрос по ним будет работать быстро?
20 фев 17, 11:02    [20227698]     Ответить | Цитировать Сообщить модератору
 Re: Тормозит запрос  [new]
Lokli
Member

Откуда:
Сообщений: 28
Кесарь
Lokli, выше уже написали: обновите статистику с полным сканированием. Должно помочь.


Подскажите, пожалуйста, это как?
20 фев 17, 11:09    [20227718]     Ответить | Цитировать Сообщить модератору
 Re: Тормозит запрос  [new]
invm
Member

Откуда: Москва
Сообщений: 9838
Lokli
Посмотрел фактический план выполнения
Вот и нам его покажите (в формате sqlplan, а не картинкой). А то гадать можно долго.
К рекомендациям оптимизатора по индексам нужно относится с осторожностью: можно насоздавать кучу индексов, когда на самом деле возможно обойтись одним.
20 фев 17, 11:15    [20227745]     Ответить | Цитировать Сообщить модератору
 Re: Тормозит запрос  [new]
Lokli
Member

Откуда:
Сообщений: 28
invm
Lokli
Посмотрел фактический план выполнения
Вот и нам его покажите (в формате sqlplan, а не картинкой). А то гадать можно долго.
К рекомендациям оптимизатора по индексам нужно относится с осторожностью: можно насоздавать кучу индексов, когда на самом деле возможно обойтись одним.

Файлик.

К сообщению приложен файл (ПланВыполнения.sqlplan - 117Kb) cкачать
20 фев 17, 12:06    [20228068]     Ответить | Цитировать Сообщить модератору
 Re: Тормозит запрос  [new]
Кесарь
Member

Откуда:
Сообщений: 677
Lokli
Кесарь
Lokli, выше уже написали: обновите статистику с полным сканированием. Должно помочь.


Подскажите, пожалуйста, это как?


https://msdn.microsoft.com/ru-ru/library/ms187348.aspx

Там есть примеры, делайте по обеим таблицам.
20 фев 17, 12:15    [20228128]     Ответить | Цитировать Сообщить модератору
 Re: Тормозит запрос  [new]
invm
Member

Откуда: Москва
Сообщений: 9838
Lokli,

Чем руководствовались при выборе порядка столбцов в индексе DBUUID_Object?
Если возможно, переделайте индекс вот таким образом:
CREATE NONCLUSTERED INDEX [DBUUID_Object] ON [dbo].[MetaData] 
(
	[DBUUID] ASC,
	[CodeTableObject] ASC,
	[CodeTypeObject] ASC,
	[NameObject] ASC
)
INCLUDE
(
 [DescrObject],[NameProps],[DescrProps],[CodeProps],[CodeProps36]
)
WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, DROP_EXISTING = ON, ONLINE = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON) ON [PRIMARY]
Для данного запроса это несколько улучшит поиск по индексу и уберет Key Lookup из MetaData.

Либо, если порядок столбцов менять нельзя, просто добавьте предложение INCLUDE.
20 фев 17, 12:29    [20228196]     Ответить | Цитировать Сообщить модератору
 Re: Тормозит запрос  [new]
invm
Member

Откуда: Москва
Сообщений: 9838
Lokli
если честно, не понимаю почему один и тот же запрос при разных параметрах, возвращая сопоставимые объёмы информации (503 и 409 строк), выполняется за столь разные промежутки времени?
Потому что обрабатывается разное число строк в MetaData дорогостоящим способом - Nested Loops + Key Lookup.
Lokli
Перестроил индексы по таблице MetaData. Обновил статистику по данным индексам.
Второе лишнее, ибо перестроение индексов обновляет статистику. Плюс более точную статистику, полученную при перестроении индекса, вы, скорее всего, благополучно заменили на более грубую.
20 фев 17, 12:33    [20228219]     Ответить | Цитировать Сообщить модератору
 Re: Тормозит запрос  [new]
Lokli
Member

Откуда:
Сообщений: 28
Кесарь,Idol_111, спасибо, помогло выполнение скрипта:

UPDATE STATISTICS MetaData
    WITH FULLSCAN;
UPDATE STATISTICS MetaDataAcc
    WITH FULLSCAN;
20 фев 17, 13:44    [20228519]     Ответить | Цитировать Сообщить модератору
 Re: Тормозит запрос  [new]
Lokli
Member

Откуда:
Сообщений: 28
invm
Lokli,
Чем руководствовались при выборе порядка столбцов в индексе DBUUID_Object?


Я руководствовался принципом "от общего к частному".
Для каждого DBUUID у меня есть объекты, которые поделены на 10 типов (CodeTypeObject). У каждого объекта есть свои свойства (NameObject, DescrObject, CodeTableObject, CodeTableObject36). У каждого объекта так же есть набор реквизитов, которые вносятся в столбцы CodeTypeProps, NameProps, DescrProps, CodeProps, CodeProps36. Фактически, в таблице, информация об одном объекте занимает несколько строк (сколько реквизитов).
Большинство запросов (~75%) у меня сводятся к вытаскиванию либо всех строк объекта, либо определенного реквизита объекта (одной строки). Есть запросы (~10%), которые вытаскивают всю информацию об объектах, исходя из их типа. Именно для них был добавлен индекс DBUUID_Object.
Но есть такие запросы, как приведенный выше, где мне нужна только информация об объекте, без его реквизитов. Именно в таких запросах скуль начинает тормозить. И я его понимаю: найти от 17 до 40 строк и потом предоставить одну.
Думаю, для таких случаев надо добавить отдельный индекс из вашего примера.
20 фев 17, 14:42    [20228786]     Ответить | Цитировать Сообщить модератору
 Re: Тормозит запрос  [new]
Lokli
Member

Откуда:
Сообщений: 28
invm
Второе лишнее, ибо перестроение индексов обновляет статистику. Плюс более точную статистику, полученную при перестроении индекса, вы, скорее всего, благополучно заменили на более грубую.

Спасибо, учту.
20 фев 17, 14:45    [20228800]     Ответить | Цитировать Сообщить модератору
 Re: Тормозит запрос  [new]
iap
Member

Откуда: Москва
Сообщений: 47145
Lokli
invm
Lokli,
Чем руководствовались при выборе порядка столбцов в индексе DBUUID_Object?


Я руководствовался принципом "от общего к частному".
Для каждого DBUUID у меня есть объекты, которые поделены на 10 типов (CodeTypeObject). У каждого объекта есть свои свойства (NameObject, DescrObject, CodeTableObject, CodeTableObject36). У каждого объекта так же есть набор реквизитов, которые вносятся в столбцы CodeTypeProps, NameProps, DescrProps, CodeProps, CodeProps36. Фактически, в таблице, информация об одном объекте занимает несколько строк (сколько реквизитов).
Большинство запросов (~75%) у меня сводятся к вытаскиванию либо всех строк объекта, либо определенного реквизита объекта (одной строки). Есть запросы (~10%), которые вытаскивают всю информацию об объектах, исходя из их типа. Именно для них был добавлен индекс DBUUID_Object.
Но есть такие запросы, как приведенный выше, где мне нужна только информация об объекте, без его реквизитов. Именно в таких запросах скуль начинает тормозить. И я его понимаю: найти от 17 до 40 строк и потом предоставить одну.
Думаю, для таких случаев надо добавить отдельный индекс из вашего примера.
Индекс используется только когда в запросе используется его первое поле.
Второе поле индекса используется, если используется первое, причём по условию точного равенства ("=").
Третье поле индекса - аналогично зависит от второго и т.д.
Поэтому, кстати, можно часто видеть одновременно индексы и (F1,F2), и (F2,F1).
Вопрос чисто технический. От всяких там "типов", "свойств" и т.п. не зависит.
20 фев 17, 15:10    [20228912]     Ответить | Цитировать Сообщить модератору
 Re: Тормозит запрос  [new]
Lokli
Member

Откуда:
Сообщений: 28
iap, а порядок в включенных столбцах (секция INCLUDE) важен?
20 фев 17, 19:26    [20230480]     Ответить | Цитировать Сообщить модератору
 Re: Тормозит запрос  [new]
iap
Member

Откуда: Москва
Сообщений: 47145
Lokli
iap, а порядок в включенных столбцах (секция INCLUDE) важен?
По-моему, нет.
20 фев 17, 19:48    [20230529]     Ответить | Цитировать Сообщить модератору
 Re: Тормозит запрос  [new]
Idol_111
Member

Откуда:
Сообщений: 633
также не помешает индекс по полям MDAcc.[DBUUID], MDAcc.[PLANID].
Судя (косвенно) по распределению данных, скорее будет использоваться он, чем сканирование.
20 фев 17, 23:33    [20231149]     Ответить | Цитировать Сообщить модератору
 Re: Тормозит запрос  [new]
Lokli
Member

Откуда:
Сообщений: 28
Взял базу, куда эти таблички реплицируются и, соответственно, в ней я обновление статистики не делал. Запустил на ней все рабочие запросы и ужаснулся. Получается пользователи ждали в приложении по пол-минуты окошек списков для выбора (и молчали!!!).
В итоге сделал следующие индексы, которые позволили без обновления статистики получать любые данные одинаково быстро.

+ Индексы MetaData
CREATE NONCLUSTERED INDEX [PK_DBUUID_CodeTableObject] ON [dbo].[MetaData] 
(	[DBUUID] ASC,
	[CodeTableObject] ASC
)
INCLUDE ( [CodeTypeObject],[NameObject],[CodeTableObject36],[CodeTypeProps],[NameProps],[CodeProps],[CodeProps36],[DescrObject],[DescrProps]
) WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON) ON [PRIMARY]
GO
CREATE NONCLUSTERED INDEX [PK_DBUUID_CodeTypeObject] ON [dbo].[MetaData] 
(	[DBUUID] ASC,
	[CodeTypeObject] ASC
)
INCLUDE ( [NameObject],[DescrObject],[CodeTableObject],[CodeTableObject36],[CodeTypeProps],[NameProps],[DescrProps],[CodeProps],[CodeProps36]
) WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON) ON [PRIMARY]
GO

+ Индексы MetaDataAcc
CREATE NONCLUSTERED INDEX [PK_DBUUID_PLANID_ID] ON [dbo].[MetaDataAcc] 
(	[DBUUID] ASC,
	[PLANID] ASC,
	[ID] ASC
)
INCLUDE ( [PLANIM],[SCHKOD],[SC0],[SC1],[SC2]
) WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON) ON [PRIMARY]
GO
CREATE NONCLUSTERED INDEX [PK_DBUUID_ID] ON [dbo].[MetaDataAcc] 
(	[DBUUID] ASC,
	[ID] ASC
)
INCLUDE ( [PLANID],[PLANIM],[SCHKOD],[SC0],[SC1],[SC2]
) WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON) ON [PRIMARY]
GO

Думаю, я хоть что-то начал понимать в индексах.
21 фев 17, 07:28    [20231430]     Ответить | Цитировать Сообщить модератору
 Re: Тормозит запрос  [new]
Lokli
Member

Откуда:
Сообщений: 28
Вот только индексы у меня теперь занимают в базе места в два раза больше чем данные. )))
Но вопрос в другом: как заставить индексы реплицироваться?
В MSDN написано следующее:
CREATE INDEX и ALTER INDEX не реплицируются, поэтому при добавлении или изменении индекса, например на издателе, необходимо создать или изменить его и на подписчике, чтобы он отразился и там.
На форуме увидел:
Glory
Создавайте констрейнты, которые создают индексы. Они реплицируются

Можно расшифровать?
21 фев 17, 08:21    [20231531]     Ответить | Цитировать Сообщить модератору
 Re: Тормозит запрос  [new]
invm
Member

Откуда: Москва
Сообщений: 9838
Lokli
Но вопрос в другом: как заставить индексы реплицироваться?
https://blogs.msdn.microsoft.com/repltalk/2012/04/03/replicating-non-clustered-indexes-improves-subscriber-query-performance/
21 фев 17, 09:01    [20231603]     Ответить | Цитировать Сообщить модератору
 Re: Тормозит запрос  [new]
Lokli
Member

Откуда:
Сообщений: 28
invm, спасибо. Сюда я не догадался заглянуть.
21 фев 17, 09:49    [20231756]     Ответить | Цитировать Сообщить модератору
 Re: Тормозит запрос  [new]
west74
Member

Откуда: Челябинск
Сообщений: 76
Приветствую

а не пробовали в качестве эксперимента, вариант "есть слона по частям?"
если результат запроса не велик может разбить сложную конструкцию left join
чтоб оптимизатор не придумывал себе порядок соединения
и получить нечто вроде :


select [PLANID],[PLANIM],[ID],...........
,MAX(SC0Descr),......
,MAX(SC1Descr),.....
,MAX(SC2Descr),.....

from (
select
SELECT MDAcc.[PLANID],MDAcc.[PLANIM],MDAcc.[ID],MDAcc.[SCHKOD],MDAcc.[SCHIM],MDAcc.[SCHV],MDAcc.[SCHKOL]
,MDAcc.[SCHSINGLE],MDAcc.[ISFOLDER],MDAcc.[ISMARK],MDAcc.[LEVEL_],MDAcc.[MDID],MDAcc.[ACTIVE]
,MDAcc.[SC0],MDAcc.[OSC0],MDAcc.[FSC0]
,IsNULL(MD0.NameObject,'') SC0Name,IsNULL(MD0.DescrObject,'') SC0Descr
,IsNULL(MD0.NameProps,'') SC0_Type,IsNULL(MD0.DescrProps,'') SC0_Kind
,IsNULL(MD0.CodeProps,0) SC0_TypeCode,IsNULL(MD0.CodeProps36,'') SC0_TypeCode36
,MDAcc.[SC1],MDAcc.[OSC1],MDAcc.[FSC1]
,'' SC1Name,'' SC1Descr
,'' SC1_Type,'' SC1_Kind
,'' SC1_TypeCode,'' SC1_TypeCode36
,MDAcc.[SC2],MDAcc.[OSC2],MDAcc.[FSC2]
,'' SC2Name,'' SC2Descr
,'' SC2_Type,'' SC2_Kind
,'' SC2_TypeCode, SC2_TypeCode36

FROM [MetaDataAcc] MDAcc
LEFT JOIN [MetaData] MD0 ON (MDAcc.[SC0]>0)AND(MDAcc.[SC0] = MD0.[CodeTableObject]) AND (MDAcc.[DBUUID] = MD0.[DBUUID])
WHERE (MDAcc.[DBUUID] = @P1) AND (MDAcc.[PLANID] = @P2)

union all

SELECT MDAcc.[PLANID],MDAcc.[PLANIM],MDAcc.[ID],MDAcc.[SCHKOD],MDAcc.[SCHIM],MDAcc.[SCHV],MDAcc.[SCHKOL]
,MDAcc.[SCHSINGLE],MDAcc.[ISFOLDER],MDAcc.[ISMARK],MDAcc.[LEVEL_],MDAcc.[MDID],MDAcc.[ACTIVE]
,MDAcc.[SC0],MDAcc.[OSC0],MDAcc.[FSC0]
,'' SC0Name,'' SC0Descr
,'' SC0_Type,'' SC0_Kind
,'' SC0_TypeCode,'' SC0_TypeCode36
,MDAcc.[SC1],MDAcc.[OSC1],MDAcc.[FSC1]
,IsNULL(MD1.NameObject,'') SC1Name,IsNULL(MD1.DescrObject,'') SC1Descr
,IsNULL(MD1.NameProps,'') SC1_Type,IsNULL(MD1.DescrProps,'') SC1_Kind
,IsNULL(MD1.CodeProps,0) SC1_TypeCode,IsNULL(MD1.CodeProps36,'') SC1_TypeCode36
,MDAcc.[SC2],MDAcc.[OSC2],MDAcc.[FSC2]
,'' SC2Name,'' SC2Descr
,'' SC2_Type,'' SC2_Kind
,'' SC2_TypeCode,'' SC2_TypeCode36

FROM [MetaDataAcc] MDAcc
LEFT JOIN [MetaData] MD1 ON (MDAcc.[SC1]>0)AND(MDAcc.[SC1] = MD1.[CodeTableObject]) AND (MDAcc.[DBUUID] = MD1.[DBUUID])
WHERE (MDAcc.[DBUUID] = @P1) AND (MDAcc.[PLANID] = @P2)

union all

SELECT MDAcc.[PLANID],MDAcc.[PLANIM],MDAcc.[ID],MDAcc.[SCHKOD],MDAcc.[SCHIM],MDAcc.[SCHV],MDAcc.[SCHKOL]
,MDAcc.[SCHSINGLE],MDAcc.[ISFOLDER],MDAcc.[ISMARK],MDAcc.[LEVEL_],MDAcc.[MDID],MDAcc.[ACTIVE]
,MDAcc.[SC0],MDAcc.[OSC0],MDAcc.[FSC0]
,IsNULL(MD0.NameObject,'') SC0Name,IsNULL(MD0.DescrObject,'') SC0Descr
,IsNULL(MD0.NameProps,'') SC0_Type,IsNULL(MD0.DescrProps,'') SC0_Kind
,IsNULL(MD0.CodeProps,0) SC0_TypeCode,IsNULL(MD0.CodeProps36,'') SC0_TypeCode36
,MDAcc.[SC1],MDAcc.[OSC1],MDAcc.[FSC1]
,'' SC1Name,'' SC1Descr
,'' SC1_Type,'' SC1_Kind
,'' SC1_TypeCode,'' SC1_TypeCode36
,MDAcc.[SC2],MDAcc.[OSC2],MDAcc.[FSC2]
,'' SC2Name,'' SC2Descr
,'' SC2_Type,'' SC2_Kind
,'' SC2_TypeCode,'' SC2_TypeCode36
FROM [MetaDataAcc] MDAcc
LEFT JOIN [MetaData] MD2 ON (MDAcc.[SC2]>0)AND(MDAcc.[SC2] = MD2.[CodeTableObject]) AND (MDAcc.[DBUUID] = MD2.[DBUUID])
WHERE (MDAcc.[DBUUID] = @P1) AND (MDAcc.[PLANID] = @P2)
) AA
group by [PLANID],[PLANIM],[ID],...........
21 фев 17, 11:24    [20232255]     Ответить | Цитировать Сообщить модератору
 Re: Тормозит запрос  [new]
Ivan Durak
Member

Откуда: Minsk!!!
Сообщений: 3754
west74
Приветствую

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

На самом деле тут вообще можно было бы три джоина MetaData заменить на ОДИН (и уйти в один хэш джоин вместо трех лупов),
но вангую, что нет смысла, слишком распределение данных неподходящее. 5.8 vs 114 тыс
21 фев 17, 12:31    [20232560]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
Все форумы / Microsoft SQL Server Ответить