Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

как обойти Timeot Expired [D6, MSSQL]

Страницы: < 1 2 3 >
tormoz © (2005-08-11 15:26:00)
Здравствуйте. Есть две таблицы: в первой 1550000 записей, во второй 950000. Необходимо выполнить запрос
SELECT pf1.* FROM pf1 INNER JOIN pfp ON pf1.SPOL = pfp.S_POL AND pf1.NPOL = pfp.N_POL
Точнее надо в первой таблице изменить значение одного поля, которое будет браться из второй таблицы по соответствию двух полей. Но не то что update, даже просто select не выполняется: пишет Timeout expired. Посоветуйте что-нибудь. Запросы пытаюсь выполнить через SQL Server Enterprise Manager.

Anatoly Podgoretsky (2005-08-11 20:42:00) [21]
sniknik © (11.08.05 20:37) [34]
Я в целом говорил, а не частное.

Fay © (11.08.05 20:39) [35]
Хотелось бы (С) Председатель

sniknik (2005-08-11 20:41:00) [22]
tormoz (11.08.05 20:32) [33]
сделай открытием курсора, сканом левой таблици с запросом на обновление для каждой записи. на сервере естественно. возможно и будет быстрее но сомневаюсь.

Fay (2005-08-11 20:39:00) [23]
2 tormoz (11.08.05 20:32) [33]
Струкатуру, индексы и план запроса мы так и не увидим?

sniknik (2005-08-11 20:37:00) [24]
Anatoly Podgoretsky © (11.08.05 19:45) [31]
Почему по одной?
субьективное мнение для данного случая, основанное на словах в вопросе
"в первой таблице изменить значение одного поля, которое будет браться из второй таблицы по соответствию двух полей"
ну вот не представляю по такому описанию изменение одной записи значениями и нескольких соответствий в другой таблице.

tormoz (2005-08-11 20:32:00) [25]
Индексы построены по всем полям, в обоих таблицах, которые участвуют в запросе. Повторяю то, что должно получится. Есть две таблицы, в которых два поля (spol, npol в одной и s_pol,n_pol в другой) задают однозначное соответствие (для каждой записи в одной таблице во второй существует только одна запись), причем в первой таблице есть записи, которым во второй нет соответствия...
надо на основании этого полю ndog первой таблицы присвоить значения ndog из второй таблицы, учитывая все условия...есть еще условие(сразу про него забыл): в первой таблице записи, в которых должно произойти изменение поля, имеют обязательный параметр wfrom=9... В общем, надо построить запрос, который заменит значение одного поля в первой таблице в соответствии со значениями полей второй...

> Ольга (11.08.05 18:43) [29]

Разницы нет, я пробовал и одно поле выбрать... Это был просто тест... мне в итоге запрос нужен не select, а update...

Anatoly Podgoretsky (2005-08-11 19:45:00) [26]
Хорошо если сервер догадается построить временный индекс, но расчитывать на это не стоит.

Anatoly Podgoretsky (2005-08-11 19:45:00) [27]
sniknik © (11.08.05 17:53) [24]
чем выбрать таблицу слева (не больше) и присоеденить к ней по одной запись таблицы права.

Почему по одной?, столько раз сколько раз будет выполнено условие соединения и если при этом не будет индексоы, то правая таблица будет полностью сканировать, вот тут и получится декартово произведение, для каждой левой записи сканирование справа. И не важно внутреннее или внешнее соединение.
Для таких записей очень важны правильные индексы, что уйти от полного сканирования таблицы. Для указаных размеров может произойти 1 472 500 000 000 сравнений, так как никаких ограничений слева нет.

Nikolay M. (2005-08-11 19:13:00) [28]

> sniknik © (11.08.05 17:53) [24]

Несколько сумбурно, но в целом понятно и, увы, неубедительно :(
Лично я на практике с таким не сталкивался, сколько статей по оптимизации и просто советов в форумах ни читал, ни разу не встречал такой "догадки". Но буду иметь ввиду, если вдруг однажды left join у меня побъет все рекорды скорости :)

Ольга (2005-08-11 18:43:00) [29]

> tormoz (11.08.05 15:26)

Все же перед update выполните select, чтобы убедиться, что таблицы правильно связаны. Видимо вы еще какое-нибудь условие связи забыли - не может так долго идти выборка. И не поленитесь прописать хоть пару полей вместо *.

Fay (2005-08-11 18:11:00) [30]
2 sniknik © (11.08.05 18:10) [27]
OK 8)

sniknik (2005-08-11 18:10:00) [31]
во. я понял. просто допишите туда к посту [12]+дополнение [15] одно большое ИМХО, и прочтите еще раз. и закончим на этом. ;о))

sniknik (2005-08-11 18:07:00) [32]
> Ни один вервер не станет его строить.
в чистом виде да. но думаю будет чтото похожее, может частями, может алгоритм улучшеный. не знаю.
но при попытках представить как это может работать, левое(/правое) обьеденение представляется всетаки проще. ;о)) все что для иннер-а и больших таблиц придумывается, все очень ресурсоемкое...

Fay (2005-08-11 17:58:00) [33]
2 sniknik © (11.08.05 17:53) [24]
Далось Вам это произведение... Ни один вервер не станет его строить.

sniknik (2005-08-11 17:53:00) [34]
> Скорее всего, это так. И что с того?
да нет. ничего. ;)
просто построить полное обьеденение и после вырезать ненужное, гораздо затратнее решение (на момент постройки, а не готового результата из которого уже все несовпадаюшее вырезано)
чем выбрать таблицу слева (не больше) и присоеденить к ней по одной запись таблицы права.
(в одном случае через умножение таблиц во втором через прибавление...)
это конечно все утрировано, при некоторых условиях (к примеру совпадениях только по одной записи), и сервер наверняка поступает не "чисто" таким образом. но догадка имеет место быть ;о)).
так слова
"в первой таблице изменить значение одного поля, которое будет браться из второй таблицы по соответствию двух полей"
воспринимаю как практически прямое указание, что совпадающих будет по одной...
а "чистое" произведение будет занимать (при 100 байтной суммовой записи) 137137 гигабайт. неудивительно что таймаут. ;о)

ну не знаю как обьяснить. ну вот - как ты думаеш? не о чемто не по поводу и т.д. а "как"?
знаеш? не знаеш? но ведь думаеш. ;о)) ну вот и тут тоже. вроде все очевидно, а обьяснить как к этому пришол тяжело. проще проверить практикой, и все.

Nikolay M. (2005-08-11 17:24:00) [35]

> sniknik © (11.08.05 16:56) [19]
> просто сдесь обьем настолько большой что не удивлюсь если
> результат обьеденения в память не помещается и в кеш на
> винт скидывается...

Скорее всего, это так. И что с того?

sniknik (2005-08-11 17:03:00) [36]
> Не вижу оснований для "меньше".
да, это я погорячился. столько же будет.

Fay (2005-08-11 16:59:00) [37]
2 sniknik © (11.08.05 16:56) [19]
>> если результат обьеденения в память не помещается
А что он (рузультат) там забыл (в памяти)?!

Fay (2005-08-11 16:57:00) [38]
2 sniknik © (11.08.05 16:53) [18]
>> см. "добавку" из [14]
Конечно, я её видел. Специально проверял - план даёт как при inner join.
>> а то и меньше
Не вижу оснований для "меньше".

sniknik (2005-08-11 16:56:00) [39]
> Nikolay M. © (11.08.05 16:53) [17]
не однозначность, догадка, но с хорошей долей вероятности (процентов 95 даю за себя ;о))).
просто сдесь обьем настолько большой что не удивлюсь если результат обьеденения в память не помещается и в кеш на винт скидывается...

sniknik (2005-08-11 16:53:00) [40]
> 1) Вам бы сцнарии для ужастиков писать.
;о)) тяжела правда жизни....

> т.к. в общем случае возвращает больше записей.
см. "добавку" из [14]. тоже самое будет, а то и меньше.
(если в правой несколько подходящий под обьеденение записей то при иннер их будет больше)

> 3) Предлагаю подождать план запроса.
можно

Страницы: < 1 2 3 >

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »