Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Какая-то непонятка творится с временными таблицами
|
|||
|---|---|---|---|
|
#18+
Создал 3 временных таблицы ( с # ) Собираю из них запрос. Вопрос почему во всех вариантах, что я пробовал ( по различным ключам ) QA всегда показывает изпользование Clustered Index-а. Хотя есть индексы, которые построены по полям кластерного индекса и лучше подходят для использования в определенных запросах ? Не понимаю, что за лажа. Объясните пожалуста. Может я где-го глюканул?? Спасибо ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.04.2001, 14:17 |
|
||
|
Какая-то непонятка творится с временными таблицами
|
|||
|---|---|---|---|
|
#18+
Использование кластерного индекса в некоторых случаях может просто означать банальный table scan. Большие таблицы-то? А то иногда серверу проще просканировать таблицу вместо использования индексов. А если уверены, что оптимазер ошибается - используйте хинты ... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.04.2001, 14:25 |
|
||
|
Какая-то непонятка творится с временными таблицами
|
|||
|---|---|---|---|
|
#18+
В том-то и трабл, что изза данного непонятного сканирования по кластерному индексу собирается все просто неимоверно долго. Хотя таблицы созданы так, чтобы этого избежать. Насчет ошибается он или нет, я не знаю, не так часто работал с #. Поэтому и спрашиваю может они так по природе своей работают. Таблицы не большие 10000, 60000, 100000 записей соответственно. Спасибо ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.04.2001, 14:32 |
|
||
|
Какая-то непонятка творится с временными таблицами
|
|||
|---|---|---|---|
|
#18+
сорри на backspace по привичке нажал ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.04.2001, 14:32 |
|
||
|
Какая-то непонятка творится с временными таблицами
|
|||
|---|---|---|---|
|
#18+
Дело в следующем. Индекс, если он создаётся в пакете, то внутри этого пакета он не виден. То же самое касается и процедур. Для примера создадим таблицу select * into #t from sysobjects Если вы напишите create index x on #t(name) select * from #t (index=x) where name='sysobjects' то получите ошибку, что такого индекса нет. Но если эти команда разделить на разные пакеты, то будет всё нормально(не забудьте потереть индекс) create index x on #t(name) go select * from #t (index=x) where name='sysobjects' И причем такая "традиция" ведется еще с 4-й версии. Возникает закономерный вопрос - что делать? Я лично ничего умного придумать не смог и пишу в этих случаях так: create index x on #t(name) exec('select * from #t (index=x) where name=''sysobjects''') С приветом Сергей PS. Надеюсь не очень запутанно? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.04.2001, 14:48 |
|
||
|
Какая-то непонятка творится с временными таблицами
|
|||
|---|---|---|---|
|
#18+
Спасибо Сергей. Это то, что я хотел услышать. Ответ оценен на 10 Как я понял. Что он мало того, что не виден в QA, он еще и не используется. Ясненько. Будем искать. Спасибо ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.04.2001, 15:08 |
|
||
|
Какая-то непонятка творится с временными таблицами
|
|||
|---|---|---|---|
|
#18+
Вариант create index x on #t(name) exec('select * from #t (index=x) where name=''sysobjects''') по некоторым причинам неудобен в ХП. Лучше всего делать две (или больше) ХП: В 1-й: создаём вр. табл., индексы, вливаем данные и вызываем 2-ю ХП. В 2-й: используем эту вр. табл. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.04.2001, 17:59 |
|
||
|
Какая-то непонятка творится с временными таблицами
|
|||
|---|---|---|---|
|
#18+
Спасибо alexeyvg Вообщем я так и делаю. Только я использую ##. По причине того, что если использовать # в текущей сессии то индексов у Вас не будет. А если в другой, то таблиц не будет. Тем не менее Спасибо alexeyvg и SergSuper ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.04.2001, 18:33 |
|
||
|
Какая-то непонятка творится с временными таблицами
|
|||
|---|---|---|---|
|
#18+
Я неоднократно создавал временные таблицы с индексами внутри процедур - никаких проблем: Например: create proc p as begin create table #t (id int identity(1,1), f varchar(3)) create index i on #t(f) select * from #t with (index (i)) where f='xyz' end go exec p go Работает на ура - никакого мата об отсутствующих индексах - проверял и в семерке и в SQL2K. Другое дело статистика - индекс создается при пустой таблице, соответственно статистики нет - если статистика не обновилась, а процесс этот хоть и автоматический, но не мгновенный, оптимизатор этот индекс без хинта использовать не будет - но сам индекс виден без проблем. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.04.2001, 18:34 |
|
||
|
Какая-то непонятка творится с временными таблицами
|
|||
|---|---|---|---|
|
#18+
Согласен с Alexander Chepack - у меня так тоже всё работает от SQL6.5 до SQL2000. И я использую вложенные процедура, что-бы им была видна статистика. 2Дмитрий Голубев: "По причине того, что если использовать # в текущей сессии то индексов у Вас не будет. А если в другой, то таблиц не будет." Я думаю, что индексов не будет (точнее, статистики), если в том-же батче, а не в той-же сесии. А использовать ## вместо # - так теряются главное преимущества вр. таблиц. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.04.2001, 19:25 |
|
||
|
Какая-то непонятка творится с временными таблицами
|
|||
|---|---|---|---|
|
#18+
К сожалению, у меня дома только 2000-к. С остальными версиями проверю на работе. Работающие конструкции: CREATE TABLE #T (IdR int NOT NULL , CONSTRAINT PKT PRIMARY KEY (IdR DESC)) ... CREATE TABLE #T (IdR int NOT NULL) CREATE INDEX #TmpIndx ON #T (IdR DESC) ... CREATE TABLE #T (IdR int NOT NULL) CREATE CLUSTERED INDEX #TmpIndx ON #T (IdR DESC) Использование SELECT * FROM #T (INDEX=#TmpIndx) НЕ приводило к ошибке. Если уж мы сошлись на том, что индекс действительно создаётся (и это, соответствующим образом, отражено в системных таблицах), то кто мешает использовать INDEX=1 (или 2, ...)? Смотрим на план: select * into #t from sysobjects create index #x on #t(name) create index #x1 on #t(id DESC) select t.* from #t t JOIN sysobjects o ON (t.name=o.name) where o.name LIKE 'sysf%' select t.* from #t t JOIN sysobjects o ON (t.id=o.id) where o.id BETWEEN 500000000 AND 800000000 Вариант с созданием пустой таблицы, созданием индексов и её последующим заполнением приводит к тем же результатам. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.04.2001, 02:06 |
|
||
|
Какая-то непонятка творится с временными таблицами
|
|||
|---|---|---|---|
|
#18+
Как обещал: create index x on #t(name) select * from #t (index=x) where name='sysobjects' приводит к ошибке ТОЛЬКО в 6.5 ... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.04.2001, 00:03 |
|
||
|
Какая-то непонятка творится с временными таблицами
|
|||
|---|---|---|---|
|
#18+
У меня стоит 2000-й Если писать select * into #t from sysobjects create index x on #t(name) select * from #t (index=x) where name='sysobjects' то всё проходит нормально. Но если написать select * into #t from sysobjects go create index x on #t(name) select * from #t (index=x) where name='sysobjects' то возникает ошибка. Причем если в первом случае попытаться посмотреть План выполнения, то тоже возникает ошибка. Но тем не менее я всё-таки был не прав. Судя по скорости выполнения запросов если индекс есть, он всё равно учитывается. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.04.2001, 11:26 |
|
||
|
Какая-то непонятка творится с временными таблицами
|
|||
|---|---|---|---|
|
#18+
Проблема с планом выполнения объясняется просто - на момент просмотра плана, временная таблица отсутствует - выделите create table ..., выполните только его, снимите выделение и можете после этого просматривать план... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.04.2001, 12:53 |
|
||
|
Какая-то непонятка творится с временными таблицами
|
|||
|---|---|---|---|
|
#18+
2 Alexander Chepack Дык и индекс отсутствует. Однако при запросе он используется, а если попросить нарисовать план - ругается. Как-то мы тут уже выясняли - получается что этот план, который рисуется, мягко говоря, не всегда соответствует тому, как в действительности выполняется. Кстати если написать как Вы говорите, то и без плана будет ругаться. select * into #t from sysobjects go select * into #t from sysobjects create proc #p as create index x on #t(name) select * from #t with (index(x)) where name='sysobjects' go #p ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.04.2001, 14:24 |
|
||
|
Какая-то непонятка творится с временными таблицами
|
|||
|---|---|---|---|
|
#18+
select * into #t from sysobjects go select * into #t from sysobjects create proc #p as create index x on #t(name) select * from #t with (index(x)) where name='sysobjects' go И ГДЕ ЭТО Я ТАК ПИСАЛ?????? У меня было: create proc p as begin create table #t (id int identity(1,1), f varchar(3)) create index i on #t(f) select * from #t with (index (i)) where f='xyz' end go exec p go ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.04.2001, 14:46 |
|
||
|
Какая-то непонятка творится с временными таблицами
|
|||
|---|---|---|---|
|
#18+
Ну тогда пардон. А как мне еще было понять такие слова? выделите create table ..., выполните только его 2-й create table конечно лишний, это понятно Ну вобщем тема наверное исчерпана ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.04.2001, 17:05 |
|
||
|
|

start [/forum/topic.php?fid=46&msg=32004800&tid=1826894]: |
0ms |
get settings: |
9ms |
get forum list: |
15ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
44ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
53ms |
get tp. blocked users: |
2ms |
| others: | 256ms |
| total: | 401ms |

| 0 / 0 |
