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

Откуда: Нижний Новгород
Сообщений: 972
нашол только [url=]https://www.sql.ru/forum/actualthread.aspx?tid=5643&pg=1[/url], тема от 2002 года и не раскрыта полностью %)

Имею 2 запроса
SELECT *
	FROM hist_chp hc
	INNER JOIN #cid t
		ON hc.id_a=t.id

SELECT *
	FROM hist_chp hc
		INNER JOIN (SELECT id FROM #cid GROUP BY id) t
			ON hc.id_a=t.id
временная #cid уже содержит уникальные ИДы. Но если первый запрос через 30 сек выдает 815тыщ записей, то во время исполнения второго через 30 сек прерываю и показывается порядка 5000 обработанных. Куда смотреть?
21 июл 09, 11:14    [7439030]     Ответить | Цитировать Сообщить модератору
 Re: Резко упала производительность в подзапросе. Что не так? О_о  [new]
Glory
Member

Откуда:
Сообщений: 104760
Смотреть в план выполнения запроса
21 июл 09, 11:17    [7439048]     Ответить | Цитировать Сообщить модератору
 Re: Резко упала производительность в подзапросе. Что не так? О_о  [new]
Senya_L
Member

Откуда: Москва
Сообщений: 5381
Hel!Riser,

сколько записей во временной таблице #cid и сколько в hist_chp?
21 июл 09, 11:28    [7439128]     Ответить | Цитировать Сообщить модератору
 Re: Резко упала производительность в подзапросе. Что не так? О_о  [new]
Ramin Hashimzade
Member

Откуда: Азербайджан, Баку
Сообщений: 9979
Блог
SELECT *
	FROM hist_chp hc
	INNER JOIN #cid t
		ON hc.id_a=t.id
если запрос возврашает 815000 записей тогда почему использовать временные таблицы?


----
www.hramin.jino-net.ru
Картинка с другого сайта.
21 июл 09, 11:30    [7439152]     Ответить | Цитировать Сообщить модератору
 Re: Резко упала производительность в подзапросе. Что не так? О_о  [new]
Алексей2003
Member

Откуда: Москва
Сообщений: 5645
может стоит индекс повесить на временную таблицу?

для спящего время бодрствования равносильно сну
21 июл 09, 11:42    [7439233]     Ответить | Цитировать Сообщить модератору
 Re: Резко упала производительность в подзапросе. Что не так? О_о  [new]
Hel!Riser
Member

Откуда: Нижний Новгород
Сообщений: 972
Senya_L
Hel!Riser,

сколько записей во временной таблице #cid и сколько в hist_chp?

в первой 27000 и во второй порядка 17 милионов

Планы такие -
  |--Hash Match(Inner Join, HASH:([t].[id])=([hc].[id_a]))
       |--Table Scan(OBJECT:([tempdb].[dbo].[#cid] AS [t]))
       |--Clustered Index Scan(OBJECT:([co_balahna].[dbo].[hist_chp].[PK_hist_chp] AS [hc]))
и второй:
  |--Hash Match(Inner Join, HASH:([tempdb].[dbo].[#cid].[id])=([hc].[id_a]))
       |--Hash Match(Aggregate, HASH:([tempdb].[dbo].[#cid].[id]))
       |    |--Table Scan(OBJECT:([tempdb].[dbo].[#cid]))
       |--Clustered Index Scan(OBJECT:([co_balahna].[dbo].[hist_chp].[PK_hist_chp] AS [hc]))


Сообщение было отредактировано: 21 июл 09, 11:57
21 июл 09, 11:56    [7439340]     Ответить | Цитировать Сообщить модератору
 Re: Резко упала производительность в подзапросе. Что не так? О_о  [new]
Бестолковая
Member

Откуда: Russia, Moscow
Сообщений: 16
да поможет вам индекс...
21 июл 09, 12:03    [7439386]     Ответить | Цитировать Сообщить модератору
 Re: Резко упала производительность в подзапросе. Что не так? О_о  [new]
Senya_L
Member

Откуда: Москва
Сообщений: 5381
Hel!Riser
Senya_L
Hel!Riser,

сколько записей во временной таблице #cid и сколько в hist_chp?

в первой 27000 и во второй порядка 17 милионов

Планы такие -
  |--Hash Match(Inner Join, HASH:([t].[id])=([hc].[id_a]))
       |--Table Scan(OBJECT:([tempdb].[dbo].[#cid] AS [t]))
       |--Clustered Index Scan(OBJECT:([co_balahna].[dbo].[hist_chp].[PK_hist_chp] AS [hc]))
и второй:
  |--Hash Match(Inner Join, HASH:([tempdb].[dbo].[#cid].[id])=([hc].[id_a]))
       |--Hash Match(Aggregate, HASH:([tempdb].[dbo].[#cid].[id]))
       |    |--Table Scan(OBJECT:([tempdb].[dbo].[#cid]))
       |--Clustered Index Scan(OBJECT:([co_balahna].[dbo].[hist_chp].[PK_hist_chp] AS [hc]))
Попробуйте создать два таких индекса:
[co_balahna].[dbo].[hist_chp] (id_a) - некластерный
и
[#cid](id) - кластерный

ЗЫ. А нельзя от дубликатов во времянке избавиться при ее наполнении? Чтобы не было необходимости в группировке.
21 июл 09, 12:22    [7439519]     Ответить | Цитировать Сообщить модератору
 Re: Резко упала производительность в подзапросе. Что не так? О_о  [new]
vino
Member

Откуда:
Сообщений: 1191
Hel!Riser
нашол только [url=]https://www.sql.ru/forum/actualthread.aspx?tid=5643&pg=1[/url], тема от 2002 года и не раскрыта полностью %)

Имею 2 запроса
SELECT *
	FROM hist_chp hc
	INNER JOIN #cid t
		ON hc.id_a=t.id

SELECT *
	FROM hist_chp hc
		INNER JOIN (SELECT id FROM #cid GROUP BY id) t
			ON hc.id_a=t.id
временная #cid уже содержит уникальные ИДы. Но если первый запрос через 30 сек выдает 815тыщ записей, то во время исполнения второго через 30 сек прерываю и показывается порядка 5000 обработанных. Куда смотреть?
Зачем извращение в виде подзапроса с группировкой?
21 июл 09, 13:10    [7439889]     Ответить | Цитировать Сообщить модератору
 Re: Резко упала производительность в подзапросе. Что не так? О_о  [new]
Hel!Riser
Member

Откуда: Нижний Новгород
Сообщений: 972
Senya_L,
на таблице по id_a есть некластеризованный индекс. На временную индекс строить не стал. Мне непонятно почему вложеный подзапрос вдруг стал конретно тормазить О_о И не важно дистинкт в нем, группировка.. по идеи же должны примерно одинаково отрабатывать, что собсна и делалось ранее. Не было такой значительной разницы

ЗЫ не суть важно про группировку. Тормаза сразу же возникают как только есть подзапрос в селекте. Вот в чем вопрос )
21 июл 09, 13:16    [7439944]     Ответить | Цитировать Сообщить модератору
 Re: Резко упала производительность в подзапросе. Что не так? О_о  [new]
Алексей2003
Member

Откуда: Москва
Сообщений: 5645
2Hel!Riser
затем, что сервер всегда пытается помочь программеру, чтобы работало быстро.
а вот программер не всегда, потому что лень, или сегодня у него нет настроения.

для спящего время бодрствования равносильно сну
21 июл 09, 13:20    [7439973]     Ответить | Цитировать Сообщить модератору
 Re: Резко упала производительность в подзапросе. Что не так? О_о  [new]
Glory
Member

Откуда:
Сообщений: 104760
Hel!Riser
Senya_L,
на таблице по id_a есть некластеризованный индекс. На временную индекс строить не стал. Мне непонятно почему вложеный подзапрос вдруг стал конретно тормазить О_о И не важно дистинкт в нем, группировка.. по идеи же должны примерно одинаково отрабатывать, что собсна и делалось ранее. Не было такой значительной разницы

Он стал тормозить за тем, что вы непонятно зачем на неидексированной куче стали делать group by
Так что подумайте над своими идеями о непринципиальности индексов и группировок
21 июл 09, 13:21    [7439981]     Ответить | Цитировать Сообщить модератору
 Re: Резко упала производительность в подзапросе. Что не так? О_о  [new]
Senya_L
Member

Откуда: Москва
Сообщений: 5381
Hel!Riser
Senya_L,
на таблице по id_a есть некластеризованный индекс. На временную индекс строить не стал. Мне непонятно почему вложеный подзапрос вдруг стал конретно тормазить О_о И не важно дистинкт в нем, группировка.. по идеи же должны примерно одинаково отрабатывать, что собсна и делалось ранее. Не было такой значительной разницы

ЗЫ не суть важно про группировку. Тормаза сразу же возникают как только есть подзапрос в селекте. Вот в чем вопрос )
Глубинные причины тормозов я объяснить не могу, а на чем тормоза - думаю можно. Посмотрите c SET STATISTICS IO. Table scan - он ведь разный бывает. Может быть один раз, а может несколько тысяч. Посмотрите, скорее всего возросло кол-во сканов по таблице [hist_chp].
автор
На временную индекс строить не стал.
Принципиально отказываетесь создать кластерный индекс? Ну-ну...
21 июл 09, 14:08    [7440317]     Ответить | Цитировать Сообщить модератору
 Re: Резко упала производительность в подзапросе. Что не так? О_о  [new]
Алексей2003
Member

Откуда: Москва
Сообщений: 5645
2Senya_L
строить неуникальный кластерный индекс? причем в этой колонке будут повторы?

для спящего время бодрствования равносильно сну
21 июл 09, 14:09    [7440330]     Ответить | Цитировать Сообщить модератору
 Re: Резко упала производительность в подзапросе. Что не так? О_о  [new]
Senya_L
Member

Откуда: Москва
Сообщений: 5381
Алексей2003
строить неуникальный кластерный индекс?
А это приравнивается к преступлению проти СУБД? :)
21 июл 09, 14:11    [7440349]     Ответить | Цитировать Сообщить модератору
 Re: Резко упала производительность в подзапросе. Что не так? О_о  [new]
Glory
Member

Откуда:
Сообщений: 104760
По словам автора темы индекс как раз можно уникальный делать - "временная #cid уже содержит уникальные ИДы."
21 июл 09, 14:13    [7440362]     Ответить | Цитировать Сообщить модератору
 Re: Резко упала производительность в подзапросе. Что не так? О_о  [new]
Senya_L
Member

Откуда: Москва
Сообщений: 5381
Glory
По словам автора темы индекс как раз можно уникальный делать - "временная #cid уже содержит уникальные ИДы."
Тогда я вообще ничего не понимаю: зачем тогда группировка по id?
21 июл 09, 14:15    [7440377]     Ответить | Цитировать Сообщить модератору
 Re: Резко упала производительность в подзапросе. Что не так? О_о  [new]
Glory
Member

Откуда:
Сообщений: 104760
Senya_L
Glory
По словам автора темы индекс как раз можно уникальный делать - "временная #cid уже содержит уникальные ИДы."
Тогда я вообще ничего не понимаю: зачем тогда группировка по id?

Потому что автор считает, что наличие индексов неприципиально. И сервер и с группировкой и без нее должен мистическим образом догадаться, что "#cid уже содержит уникальные ИДы" и не делать группировку. Тревиальный искусственный интелект в действии так сказать
21 июл 09, 14:18    [7440403]     Ответить | Цитировать Сообщить модератору
 Re: Резко упала производительность в подзапросе. Что не так? О_о  [new]
Hel!Riser
Member

Откуда: Нижний Новгород
Сообщений: 972
Glory
Потому что автор считает, что наличие индексов неприципиально. И сервер и с группировкой и без нее должен мистическим образом догадаться, что "#cid уже содержит уникальные ИДы" и не делать группировку. Тревиальный искусственный интелект в действии так сказать


потому что INNER JOIN и должен быть стоочково в #cid уникальность, дабы не расплодились лишние данные :)

Замена подзапроса на
SELECT *
	FROM hist_chp hc
		INNER JOIN (SELECT DISTINCT id FROM #cid) t
			ON hc.id_a=t.id
также никчему не привел.
Но если подзапрос вывести из селекта -
SELECT id INTO #t FROM #cid GROUP BY id
SELECT *
	FROM hist_chp hc
		INNER JOIN #t t
			ON hc.id_a=t.id
DROP TABLE #t
то сразу вс:е начиает летать.
Что вот это за чудо такое из второго плана? Из-за него вс:Е похоже встает (
|--Hash Match(Aggregate, HASH:([tempdb].[dbo].[#cid].[id]))
       |    |--Table Scan(OBJECT:([tempdb].[dbo].[#cid]))
21 июл 09, 14:30    [7440495]     Ответить | Цитировать Сообщить модератору
 Re: Резко упала производительность в подзапросе. Что не так? О_о  [new]
Алексей2003
Member

Откуда: Москва
Сообщений: 5645
2Senya_L
потому что на неуникальное значение добавляется уникальный суффикс, и он становится уникальным. т.е. увеличивает размер индекса.

для спящего время бодрствования равносильно сну
21 июл 09, 14:30    [7440498]     Ответить | Цитировать Сообщить модератору
 Re: Резко упала производительность в подзапросе. Что не так? О_о  [new]
Glory
Member

Откуда:
Сообщений: 104760
Hel!Riser
Glory
Потому что автор считает, что наличие индексов неприципиально. И сервер и с группировкой и без нее должен мистическим образом догадаться, что "#cid уже содержит уникальные ИДы" и не делать группировку. Тревиальный искусственный интелект в действии так сказать


потому что INNER JOIN и должен быть стоочково в #cid уникальность, дабы не расплодились лишние данные :)

Еще одна супер идея. Об уникальности значений с столбце сервер может узнать только из уникального индекса.

Замена group by на distinct вообще шедевр.
21 июл 09, 14:35    [7440532]     Ответить | Цитировать Сообщить модератору
 Re: Резко упала производительность в подзапросе. Что не так? О_о  [new]
Senya_L
Member

Откуда: Москва
Сообщений: 5381
Алексей2003
2Senya_L
потому что на неуникальное значение добавляется уникальный суффикс, и он становится уникальным. т.е. увеличивает размер индекса.

для спящего время бодрствования равносильно сну
Я знаю, что на низком уровне у всех кластерных индексов ключи уникальны. Но это не столь принципиально, имхо. Тем более спорим мы зазря: а автора-то этот столбец уникален :)

Hel!Riser
то сразу вс:е начиает летать.
30 сек на запрос - это по-Вашему "летает"?
Включите в индекс по id_a все прочие столбцы и если сервер выберет MERGE JOIN для слияния - вот тогда Вы увидите как оно летает. :)
21 июл 09, 14:43    [7440588]     Ответить | Цитировать Сообщить модератору
 Re: Резко упала производительность в подзапросе. Что не так? О_о  [new]
Hel!Riser
Member

Откуда: Нижний Новгород
Сообщений: 972
Glory

Замена group by на distinct вообще шедевр.

отойду от темы - в чем принципиальная разница пользования написания DISTINCT против GROUP BY если результат выполнения и его планы идентичны? О_о
21 июл 09, 15:00    [7440733]     Ответить | Цитировать Сообщить модератору
 Re: Резко упала производительность в подзапросе. Что не так? О_о  [new]
Senya_L
Member

Откуда: Москва
Сообщений: 5381
Hel!Riser
Glory

Замена group by на distinct вообще шедевр.

отойду от темы - в чем принципиальная разница пользования написания DISTINCT против GROUP BY если результат выполнения и его планы идентичны? О_о
Вот именно, что разницы особой нет. Что GROUP BY, что DISTINCT сводится к сортировке.

Тоже отойду от темы. В чем насущная необходимость ставить оптимизатор в интересную позу, делая группировку по столбцу с уникальными значениями?
автор
дабы не расплодились лишние данные :)
Как они "расплодятся"? Можете пример показать модельный?
21 июл 09, 15:05    [7440764]     Ответить | Цитировать Сообщить модератору
 Re: Резко упала производительность в подзапросе. Что не так? О_о  [new]
Glory
Member

Откуда:
Сообщений: 104760
Hel!Riser
Glory

Замена group by на distinct вообще шедевр.

отойду от темы - в чем принципиальная разница пользования написания DISTINCT против GROUP BY если результат выполнения и его планы идентичны? О_о

В том то и дело, что ни в чем
Только вопрос, а зачем вообще DISTINCT или GROUP BY по полю, где и так уникальные значения, так и остался без ответа
21 июл 09, 15:10    [7440798]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
Все форумы / Microsoft SQL Server Ответить