Главная страница
    Top.Mail.Ru    Яндекс.Метрика
Форум: "Прочее";
Текущий архив: 2007.06.10;
Скачать: [xml.tar.bz2];

Вниз

In или =   Найти похожие ветки 

 
novoalex ©   (2007-05-18 14:38) [0]

Наблюдаются упреки в ветке
http://delphimaster.net/view/3-1179436348/
По поводу in и = в запросах.
Справедливы ли последние утверждения?

Замечу лишь одно.
С моей таблицей (записей 1 288 546):
(Компьютер на котором БД старенький.)
Запрос с In выполняется 53 с.
Запрос с = выполняется 1:14 с.


 
stone ©   (2007-05-18 14:43) [1]

А СУБД ты так и не указал.


 
novoalex ©   (2007-05-18 14:45) [2]


> stone ©   (18.05.07 14:43) [1]

MS SQL Server 2000


 
clickmaker ©   (2007-05-18 14:45) [3]

in и max в принципе вещи логически несовместимые


 
Sergey13 ©   (2007-05-18 14:49) [4]

> [0] novoalex ©   (18.05.07 14:38)
> Запрос с In выполняется 53 с.
> Запрос с = выполняется 1:14 с.

Один и тот-же запрос? Можно его (их) глянуть?
В любом случае только план выполнения запроса даст окончательный ответ что и как.


 
stone ©   (2007-05-18 14:50) [5]

оптимизатор по любому преобразует твой in к =
так что тут без разницы

ты первым какой запрос выполнял с in или с =


 
Jan1   (2007-05-18 14:58) [6]

я всегда стараюсь уходить от in к exists, потому как сервер раскладывает эти in-ы на or-ы, что в свою очередь влечет и тормоза, а в некоторых случаях и вовсе свал.


 
Gadenysh   (2007-05-18 15:02) [7]

не наблюдал "свалов" при работе с IN. как вы их добиваетесь


 
Sergey13 ©   (2007-05-18 15:04) [8]

> [6] Jan1   (18.05.07 14:58)

ИМХО, тормоза влечет не раскложение in-ов на or-ы, а то, есть ли в подзапросе ссылка на внешнюю таблицу. Т.е. если IN выполняется для каждой записи главной таблицы, тогда тормоза практически обеспечены. Если выборка из подзапроса стабильна то тормоза не существенны. То-же самое и с exists.


 
clickmaker ©   (2007-05-18 15:11) [9]


> как вы их добиваетесь

при грамотном подходе можно завалить любой сервер


 
novoalex ©   (2007-05-18 15:27) [10]


> Sergey13 ©   (18.05.07 14:49) [4]


SELECT     *
FROM         tab_Ras tt
WHERE     (kod IN -- Ñîîòâåòñòâèíî çàìåíÿåìî íà =
                         (SELECT     MAX(kod) AS kod
                           FROM          tab_Ras dd
                           WHERE      tt.ls = dd.ls))



> stone ©   (18.05.07 14:50) [5]

Ïåðâûé IN


 
clickmaker ©   (2007-05-18 15:31) [11]


> [10] novoalex ©   (18.05.07 15:27)

сколько серий экспериментов провел? кэширование и общую загрузку системы учитывал?
результат всегда один и тот же?


 
novoalex ©   (2007-05-18 15:34) [12]


> clickmaker ©   (18.05.07 15:31) [11]


> сколько серий экспериментов провел:
3

> кэширование и общую загрузку системы учитывал:
нет

> результат всегда один и тот же:
+/- но in всеравно быстрее.


 
Sergey13 ©   (2007-05-18 15:40) [13]

> [10] novoalex ©   (18.05.07 15:27)

Это не очень показательный запрос, ИМХО, так как таблица завязывается сама на себя. А том топике, что ты привел были 2 таблицы.


 
novoalex ©   (2007-05-18 15:45) [14]

All Question:
Каким еще более рациональным способом можно с одной таблицы вытащить последнии записи по лицевым или намерам договоров... ?


 
Sergey13 ©   (2007-05-18 15:49) [15]

> [14] novoalex ©   (18.05.07 15:45)
> более рациональным

Насколько "более"? Процентов на 10 хватит? 8-)
Можно например хранить ссылку на последнее значение. Тоже вариант.


 
tesseract ©   (2007-05-18 15:53) [16]


> Запрос с In выполняется 53 с.Запрос с = выполняется 1:14
> с.


Если я правильно понимаю обращение к файлам БД, то всё зависит от того, насколько грамотно построена база и главное индексы.

При нормальных индексах и не сильно дефрагментированном файле обращение "=" должно быть быстрее "in". Поскольку сравнивать приходиться не с одним значением, а с несколькими. С другой стороны если идёт последовательность кодов (1001, 1002, 1003)  выборка будет практически равна по времени.    

Хотя выкладки для работы без SQL-оптимизатора. Его поведение на 90% тайна великая есть.


 
Игорь Шевченко ©   (2007-05-18 16:18) [17]

так как select max(foo) возвращает всегда одну запись, какой смысл испльзовать IN, который в принципе предназначен для поиска в списке.

Это такая своеобразная форма мазохизма у пользователей MS SQL Server 2000 ?


 
stone ©   (2007-05-18 16:56) [18]


> Это такая своеобразная форма мазохизма у пользователей MS
> SQL Server 2000 ?

у пользователя :)


> novoalex ©

Есть еще вариант

SELECT     tt.*
FROM         tab_Ras tt
 inner join (SELECT MAX(kod) AS kod, ls  FROM tab_Ras group by Ls) dd on tt.ls = dd.ls and tt.Kod = dd.Kod


 
novoalex ©   (2007-05-19 09:42) [19]


> stone ©   (18.05.07 16:56) [18]


> SELECT     tt.*
> FROM         tab_Ras tt
>  inner join (SELECT MAX(kod) AS kod, ls  FROM tab_Ras group
> by Ls) dd on tt.ls = dd.ls and tt.Kod = dd.Kod


Запрос выполняется за 36 с.    8-)



Страницы: 1 вся ветка

Форум: "Прочее";
Текущий архив: 2007.06.10;
Скачать: [xml.tar.bz2];

Наверх





Память: 0.49 MB
Время: 0.065 c
11-1161750263
Lari
2006-10-25 08:24
2007.06.10
Ошибка чтения файла при использовании PStream


1-1176448091
tytus
2007-04-13 11:08
2007.06.10
FastReport 4 - закрасить Memo через один.


15-1179109292
Slider007
2007-05-14 06:21
2007.06.10
С днем рождения ! 13 мая


2-1179754764
Bad_B
2007-05-21 17:39
2007.06.10
Что-то вроде триалки:-)


3-1174363086
Lex_!
2007-03-20 06:58
2007.06.10
Заголовки в гриде





Afrikaans Albanian Arabic Armenian Azerbaijani Basque Belarusian Bulgarian Catalan Chinese (Simplified) Chinese (Traditional) Croatian Czech Danish Dutch English Estonian Filipino Finnish French
Galician Georgian German Greek Haitian Creole Hebrew Hindi Hungarian Icelandic Indonesian Irish Italian Japanese Korean Latvian Lithuanian Macedonian Malay Maltese Norwegian
Persian Polish Portuguese Romanian Russian Serbian Slovak Slovenian Spanish Swahili Swedish Thai Turkish Ukrainian Urdu Vietnamese Welsh Yiddish Bengali Bosnian
Cebuano Esperanto Gujarati Hausa Hmong Igbo Javanese Kannada Khmer Lao Latin Maori Marathi Mongolian Nepali Punjabi Somali Tamil Telugu Yoruba
Zulu
Английский Французский Немецкий Итальянский Португальский Русский Испанский