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

Необходимо использовать в хранимых процедурах, для заполнения примерно до 50000 (чаще всего до 1000-5000 записей) записей их редактирование, возможно удаление некоторых. Процедура будет возвращать "клиенту" дата-сет т.е. в конце хранимой процедуры будет SELECT * FROM @T ORDER BY... или SELECT * FROM #T ORDER BY...

Сейчас не вижу разницы в скорости, работая с определёнными данными, но есть сомнения)))
что лучше всего использовать, что производительней
И ещё вопрос попутный, я так понимаю для табличных переменных (@) нельзя создавать индексы (CREATE INDEX), кроме тех, которые в констрейн (PRIMARY KEY, UNIQUE)

Заранее спасибо за советы.
16 июн 15, 09:58    [17774620]     Ответить | Цитировать Сообщить модератору
 Re: Что лучше в производительности: Временная таблица (#) или табличная переменная (@)  [new]
Glory
Member

Откуда:
Сообщений: 104751
igor888
что лучше всего использовать, что производительней

Кто сильнее - слон или кит ?


igor888
И ещё вопрос попутный, я так понимаю для табличных переменных (@) нельзя создавать индексы (CREATE INDEX), кроме тех, которые в констрейн (PRIMARY KEY, UNIQUE)

Да
16 июн 15, 10:01    [17774649]     Ответить | Цитировать Сообщить модератору
 Re: Что лучше в производительности: Временная таблица (#) или табличная переменная (@)  [new]
igor888
Guest
Glory,

Кто сильнее - слон или кит ?

Вот и я не знаю... поэтому и пишу
16 июн 15, 10:06    [17774686]     Ответить | Цитировать Сообщить модератору
 Re: Что лучше в производительности: Временная таблица (#) или табличная переменная (@)  [new]
Glory
Member

Откуда:
Сообщений: 104751
igor888
Вот и я не знаю... поэтому и пишу

Как вы думате, зачем иметь 2 разных компонента, если один всегда быстрее лучше второго и подходит для всех задач ?
16 июн 15, 10:10    [17774719]     Ответить | Цитировать Сообщить модератору
 Re: Что лучше в производительности: Временная таблица (#) или табличная переменная (@)  [new]
igor888
Guest
Glory
igor888
Вот и я не знаю... поэтому и пишу

Как вы думате, зачем иметь 2 разных компонента, если один всегда быстрее лучше второго и подходит для всех задач ?


Я не утверждаю, что один всегда будет лучше другого. Я описал основные критерии работы, и попросил совета что лучше в этом случае использовать.
16 июн 15, 10:16    [17774754]     Ответить | Цитировать Сообщить модератору
 Re: Что лучше в производительности: Временная таблица (#) или табличная переменная (@)  [new]
Glory
Member

Откуда:
Сообщений: 104751
igor888
и попросил совета что лучше в этом случае использовать.

Берете Профайлер и сравниваете.
16 июн 15, 10:18    [17774769]     Ответить | Цитировать Сообщить модератору
 Re: Что лучше в производительности: Временная таблица (#) или табличная переменная (@)  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31956
igor888
Я описал основные критерии работы, и попросил совета что лучше в этом случае использовать.

igor888
чаще всего до 1000-5000 записей

Используйте таблицы-переменные, если записей до нескольких тысяч, и запросы простые.

Временные таблицы будут лучше, если записей очень много, или если таблицы участвуют в очень сложных запросах. Тогда сервер сможет по статистикам выбрать более оптимальные планы выполнения.
igor888
я так понимаю для табличных переменных (@) нельзя создавать индексы (CREATE INDEX), кроме тех, которые в констрейн (PRIMARY KEY, UNIQUE)
Да.
Но в общем, можно делать индекс на любую колнку, создавая UNIQUE, с включением в конце уникального поля, это несколько уменьшает ограничения.
16 июн 15, 10:21    [17774794]     Ответить | Цитировать Сообщить модератору
 Re: Что лучше в производительности: Временная таблица (#) или табличная переменная (@)  [new]
igor888
Guest
alexeyvg,

Спасибо.

Используя табличные переменные (@) и в последствии для более быстрой обработки в конструкции WHERE стоит ли индексировать поля (которые участвуют в WHERE) через UNUQUE?
16 июн 15, 10:29    [17774853]     Ответить | Цитировать Сообщить модератору
 Re: Что лучше в производительности: Временная таблица (#) или табличная переменная (@)  [new]
churupaha
Member

Откуда: Краснодар
Сообщений: 1015
каждую неделю такая тема всплывает.
16 июн 15, 10:37    [17774933]     Ответить | Цитировать Сообщить модератору
 Re: Что лучше в производительности: Временная таблица (#) или табличная переменная (@)  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31956
igor888
Используя табличные переменные (@) и в последствии для более быстрой обработки в конструкции WHERE стоит ли индексировать поля (которые участвуют в WHERE) через UNUQUE?
Нужно сравнивать планы выполнения, зависит от условий запроса и от данных.
Допустим, если в таблице 1000 коротких записей, и она умещается в одну страницу памяти, то использование индекса бессмысленно и невозможно.
16 июн 15, 10:56    [17775092]     Ответить | Цитировать Сообщить модератору
 Re: Что лучше в производительности: Временная таблица (#) или табличная переменная (@)  [new]
мигель1
Member

Откуда:
Сообщений: 3236
я сделал следующие выводы. лучше использовать временные таблицы. т.к удобнее для отладки. иначе постоянно ругается на отсуствие объявлений переменных
16 июн 15, 12:03    [17775647]     Ответить | Цитировать Сообщить модератору
 Re: Что лучше в производительности: Временная таблица (#) или табличная переменная (@)  [new]
o-o
Guest
мигель1
я сделал следующие выводы. лучше использовать временные таблицы. т.к удобнее для отладки. иначе постоянно ругается на отсуствие объявлений переменных

на ПТ все разбежались по отпускам?
у меня хорошая память на лица, в особенности на "вбрасывателей"
(кто не верит, загляните в профиль товарища мигель1 )

мигель1,
меняйте ветку, у нас тоже лето
+ давно всем надоело, ибо
churupaha
каждую неделю такая тема всплывает.
16 июн 15, 12:17    [17775721]     Ответить | Цитировать Сообщить модератору
 Re: Что лучше в производительности: Временная таблица (#) или табличная переменная (@)  [new]
Владислав Колосов
Member

Откуда:
Сообщений: 8807
Для табличных переменных оптимизатор всегда считает количество строк = 1.
Табличные переменные предназначены для передачи данных в качестве параметра.

Они не предназначены для "быстрее" или "медленнее".
16 июн 15, 12:49    [17775926]     Ответить | Цитировать Сообщить модератору
 Re: Что лучше в производительности: Временная таблица (#) или табличная переменная (@)  [new]
ЕвгенийВ
Member

Откуда: Москва
Сообщений: 4994
Glory
igor888
что лучше всего использовать, что производительней

Кто сильнее - слон или кит ?

википедия
Синий кит (также голубой кит, или блюва́л[1], лат. Balaenoptera musculus) — морское животное из отряда китообразных, относящееся к усатым китам (род полосатиков). Самый большой кит, самое большое современное животное, а также, вероятно, крупнейшее из всех животных, когда-либо обитавших на Земле. Его длина достигает 33 метров, а вес может значительно превышать 150 тонн.
16 июн 15, 13:38    [17776315]     Ответить | Цитировать Сообщить модератору
 Re: Что лучше в производительности: Временная таблица (#) или табличная переменная (@)  [new]
Glory
Member

Откуда:
Сообщений: 104751
ЕвгенийВ
Glory
пропущено...

Кто сильнее - слон или кит ?

википедия
Синий кит (также голубой кит, или блюва́л[1], лат. Balaenoptera musculus) — морское животное из отряда китообразных, относящееся к усатым китам (род полосатиков). Самый большой кит, самое большое современное животное, а также, вероятно, крупнейшее из всех животных, когда-либо обитавших на Земле. Его длина достигает 33 метров, а вес может значительно превышать 150 тонн.

Это ответ на вопрос, кто _сильнее_ ? Или кто жирнее ?
16 июн 15, 13:40    [17776344]     Ответить | Цитировать Сообщить модератору
 Re: Что лучше в производительности: Временная таблица (#) или табличная переменная (@)  [new]
ЕвгенийВ
Member

Откуда: Москва
Сообщений: 4994
Glory,
12000 кг vs 150000 кг.
16 июн 15, 13:54    [17776456]     Ответить | Цитировать Сообщить модератору
 Re: Что лучше в производительности: Временная таблица (#) или табличная переменная (@)  [new]
Glory
Member

Откуда:
Сообщений: 104751
ЕвгенийВ
Glory,
12000 кг vs 150000 кг.

Прочитайте в википедии, в чем мерятеся сила, а не масса
16 июн 15, 13:57    [17776485]     Ответить | Цитировать Сообщить модератору
 Re: Что лучше в производительности: Временная таблица (#) или табличная переменная (@)  [new]
o-o
Guest
википедия
Синий кит (также голубой кит, или блюва́л

статья явно для иностранцев.
у наших людей нет сомнений, куда падает ударение в этом слове
16 июн 15, 14:54    [17776949]     Ответить | Цитировать Сообщить модератору
 Re: Что лучше в производительности: Временная таблица (#) или табличная переменная (@)  [new]
MSSQLBug
Guest
Владислав Колосов
Для табличных переменных оптимизатор всегда считает количество строк = 1.

DECLARE @t TABLE (n int)
INSERT INTO @t(n) VALUES (1), (2), (3), (4), (5), (6), (7)
SELECT *
FROM @t as a 
OPTION (RECOMPILE)

И в плане: предполагаемое количество строк: 7
16 июн 15, 17:51    [17778039]     Ответить | Цитировать Сообщить модератору
 Re: Что лучше в производительности: Временная таблица (#) или табличная переменная (@)  [new]
Владислав Колосов
Member

Откуда:
Сообщений: 8807
MSSQLBug,
трюк с OPTION (RECOMPILE)?
16 июн 15, 17:58    [17778084]     Ответить | Цитировать Сообщить модератору
 Re: Что лучше в производительности: Временная таблица (#) или табличная переменная (@)  [new]
MSSQLBug
Guest
Владислав Колосов
MSSQLBug,
трюк с OPTION (RECOMPILE)?

Да.
17 июн 15, 09:20    [17780084]     Ответить | Цитировать Сообщить модератору
 Re: Что лучше в производительности: Временная таблица (#) или табличная переменная (@)  [new]
человек_ниоткуда
Guest
Вот немного перевёл тебе.

@ = # - таблица в tempdb
@ - статистики на таблице создать нельзя, даже если статистики неявно есть (index), они не учитываются оптимизатором. Поэтому изменения в данных таблиц @ не приводят к рекомпиляциям. Однако, в момент компиляции запроса, учитывается количество записей в @. И кстати, можно прописывать primary key, т.е. делать индекс неявно в ней.
# - видна всем в сессии (## всем ваще).
@ - видна внутри variable scope.
# (да и ##) - умрёт, как только умрёт сессия её создавшая. Кстати не все это знают про ##.
@ - умрёт по выходу из variable scope её создавшем.

Использование @ таблиц хорошо применять, там где можно применить кучку переменных (да и они тоже переменные). Вот например тут табличная переменная будет очень кстати.
select * from MyTable where id in (@A, @B, @C);

Но не забывайте про parameter sniffing.
17 июн 15, 10:20    [17780355]     Ответить | Цитировать Сообщить модератору
 Re: Что лучше в производительности: Временная таблица (#) или табличная переменная (@)  [new]
iap
Member

Откуда: Москва
Сообщений: 47142
человек_ниоткуда
(да и ##) - умрёт, как только умрёт сессия её создавшая. Кстати не все это знают про ##.
https://msdn.microsoft.com/ru-ru/library/ms174979(v=sql.100).aspx
Глобальные временные таблицы автоматически удаляются при завершении сеанса, создавшего таблицу, и прекращении обращения к ним всех прочих задач. Связь между задачей и таблицей поддерживается только на время выполнения отдельной инструкции Transact-SQL. Это означает, что глобальная временная таблица удаляется после выполнения последней инструкции языка Transact-SQL, активно обращавшейся к ней во время завершения создавшего таблицу сеанса.
17 июн 15, 10:32    [17780426]     Ответить | Цитировать Сообщить модератору
 Re: Что лучше в производительности: Временная таблица (#) или табличная переменная (@)  [new]
Сон Веры Павловны
Member

Откуда:
Сообщений: 6201
человек_ниоткуда
И кстати, можно прописывать primary key, т.е. делать индекс неявно в ней.

И unique key тоже вполне можно. И с указанием clustered/nonclustered для обоих видов ключей.
17 июн 15, 10:49    [17780545]     Ответить | Цитировать Сообщить модератору
 Re: Что лучше в производительности: Временная таблица (#) или табличная переменная (@)  [new]
Владислав Колосов
Member

Откуда:
Сообщений: 8807
MSSQLBug
Владислав Колосов
MSSQLBug,
трюк с OPTION (RECOMPILE)?

Да.


Этот трюк лишь обманывает план запроса, попробуйте сджойнить таблицу с переменной и увидите, что в ней оптимизатор предполагает найти лишь одну запись, а не семь.
17 июн 15, 11:19    [17780765]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
Все форумы / Microsoft SQL Server Ответить