SQL

← →
Игорь Шевченко © (2008-05-21 23:12) [40]

MsGuns © (21.05.08 23:08) [39]

> Ни фиганюшки ! За одним исключением - если в результате
> "внутришних" селекций не будут выбираться и кучковаться
> на сервере же хучи отуенные промежуточных записей.

Так от количества возвращаемых запросом записей или от количества шагов обработки запроса и записей, участвующих в получении результирующего множества ? :)

А то мне не составит труда написать запрос, возвращающий одну запись и работающий пару суток :)

← →
MsGuns © (2008-05-21 23:13) [41]

Короче, просто пример.

Запрос 1. Море джоинов, причем не по ключам и даже (Боже оборони !) по стринговым связкам, причем не просто стрингов, а всяких там тримов, кастов, конвертов и пр. из 10 таблиц. Однако запрос заведомо не должен вернуть НИ ОДНОЙ записи ! Каждая из 10 таблиц содержит мульен записей

Запрос 2. Классика жанра "Select * from Table" из тэйбла размером 10 000000 записей.

Вопрос на засыпку - какой запрос выполнится шустрее ?

;)

← →
Loginov Dmitry © (2008-05-21 23:15) [42]

> Вопрос на засыпку - какой запрос выполнится шустрее ?

Второй выполнится за 0 мс?

← →
Игорь Шевченко © (2008-05-21 23:16) [43]

MsGuns © (21.05.08 23:13) [41]

> Вопрос на засыпку - какой запрос выполнится шустрее ?

Неизвестно.

← →
Игорь Шевченко © (2008-05-21 23:16) [44]

MsGuns © (21.05.08 23:13) [41]

> и даже (Боже оборони !) по стринговым связкам

А какая разница, по чему связывать ?

← →
Игорь Шевченко © (2008-05-21 23:27) [45]

Кстати о времени:

TEST@ora10> create table foo as select * from all_objects where (1=0);

Table created.

TEST@ora10> set timing on
TEST@ora10> insert into foo select * from all_objects;

40772 rows created.

Elapsed: 00:00:09.87
TEST@ora10> commit;

Commit complete.

Elapsed: 00:00:00.01
TEST@ora10> insert into foo select * from foo union all select * from foo;

81544 rows created.

Elapsed: 00:00:02.37
TEST@ora10> commit;

Commit complete.

Elapsed: 00:00:00.01
TEST@ora10> insert into foo select * from foo union all select * from foo;

244632 rows created.

Elapsed: 00:00:07.78
TEST@ora10> commit;

Commit complete.

Elapsed: 00:00:00.01
TEST@ora10> insert into foo select * from foo union all select * from foo;

733896 rows created.

Elapsed: 00:00:28.84
TEST@ora10>

Первый запрос выполнялся 9 секунд для получения 40 тысяч записей, потому что

select * from all_objects where (1=0);

no rows selected

Elapsed: 00:00:00.00

Execution Plan
----------------------------------------------------------
Plan hash value: 2338933161

----------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
----------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 86 | 0 (0)| |
|* 1 | TABLE ACCESS BY INDEX ROWID | SUM$ | 1 | 8 | 1 (0)| 00:00:01 |
|* 2 | INDEX UNIQUE SCAN | I_SUM$_1 | 1 | | 0 (0)| 00:00:01 |
|* 3 | FILTER | | | | | |
|* 4 | FILTER | | | | | |
|* 5 | HASH JOIN | | 59458 | 4993K| 183 (13)| 00:00:03 |
| 6 | TABLE ACCESS FULL | USER$ | 75 | 1125 | 3 (0)| 00:00:01 |
|* 7 | TABLE ACCESS FULL | OBJ$ | 59458 | 4122K| 178 (12)| 00:00:03 |
|* 8 | TABLE ACCESS BY INDEX ROWID | IND$ | 1 | 8 | 2 (0)| 00:00:01 |
|* 9 | INDEX UNIQUE SCAN | I_IND1 | 1 | | 1 (0)| 00:00:01 |
| 10 | NESTED LOOPS | | 1 | 24 | 2 (0)| 00:00:01 |
|* 11 | INDEX RANGE SCAN | I_OBJAUTH1 | 1 | 11 | 2 (0)| 00:00:01 |
|* 12 | FIXED TABLE FULL | X$KZSRO | 1 | 13 | 0 (0)| 00:00:01 |
|* 13 | FIXED TABLE FULL | X$KZSPR | 1 | 26 | 0 (0)| 00:00:01 |
|* 14 | FIXED TABLE FULL | X$KZSPR | 1 | 26 | 0 (0)| 00:00:01 |
|* 15 | FIXED TABLE FULL | X$KZSPR | 1 | 26 | 0 (0)| 00:00:01 |
|* 16 | FIXED TABLE FULL | X$KZSPR | 1 | 26 | 0 (0)| 00:00:01 |
|* 17 | FIXED TABLE FULL | X$KZSPR | 1 | 26 | 0 (0)| 00:00:01 |
|* 18 | FIXED TABLE FULL | X$KZSPR | 1 | 26 | 0 (0)| 00:00:01 |
|* 19 | FIXED TABLE FULL | X$KZSPR | 1 | 26 | 0 (0)| 00:00:01 |
|* 20 | FIXED TABLE FULL | X$KZSPR | 1 | 26 | 0 (0)| 00:00:01 |
|* 21 | FIXED TABLE FULL | X$KZSPR | 1 | 26 | 0 (0)| 00:00:01 |
|* 22 | FIXED TABLE FULL | X$KZSPR | 1 | 26 | 0 (0)| 00:00:01 |
|* 23 | FIXED TABLE FULL | X$KZSPR | 1 | 26 | 0 (0)| 00:00:01 |
|* 24 | FIXED TABLE FULL | X$KZSPR | 1 | 26 | 0 (0)| 00:00:01 |
|* 25 | FIXED TABLE FULL | X$KZSPR | 1 | 26 | 0 (0)| 00:00:01 |
|* 26 | FIXED TABLE FULL | X$KZSPR | 1 | 26 | 0 (0)| 00:00:01 |
|* 27 | FIXED TABLE FULL | X$KZSPR | 1 | 26 | 0 (0)| 00:00:01 |
|* 28 | FIXED TABLE FULL | X$KZSPR | 1 | 26 | 0 (0)| 00:00:01 |
|* 29 | FIXED TABLE FULL | X$KZSPR | 1 | 26 | 0 (0)| 00:00:01 |
|* 30 | FIXED TABLE FULL | X$KZSPR | 1 | 26 | 0 (0)| 00:00:01 |
|* 31 | FIXED TABLE FULL | X$KZSPR | 1 | 26 | 0 (0)| 00:00:01 |
|* 32 | FIXED TABLE FULL | X$KZSPR | 1 | 26 | 0 (0)| 00:00:01 |
|* 33 | FIXED TABLE FULL| X$KZSPR | 1 | 26 | 0 (0)| 00:00:01 |
| 34 | VIEW | | 1 | 13 | 2 (0)| 00:00:01 |
| 35 | FAST DUAL | | 1 | | 2 (0)| 00:00:01 |
-----------------------------------------------------------------------------

второй запрос на получение 80000 строк выполнялся уже 2 секунды.

Охохонюшки..
Сервер на то он и сервер, что, сволочь, использует кэши ;)
Опять подтасовываем ?

Для чистоты эксперимента надо:
а) Все выполнять на "гуляющем" сервере
б) Рвать коннект после каждого запроса и устанавливать заново дперед следующим
в) В качестве подопытных таблиц не брать те, у которых 2-3 инт-поля

Про стринги.
Ты всерьез счиатешь, что серверу пофиг, какое поле обрабатывать - числовое или стринговое ..сот байт длиной - на скорости выборок это не сказывается ?

MsGuns © (22.05.08 09:10) [46]

> Сервер на то он и сервер, что, сволочь, использует кэши
> ;)
> Опять подтасовываем ?

я тебе открою секрет - view all_objects оно в кеше чуть ли не при старте сервера.

> а) Все выполнять на "гуляющем" сервере

Незнаком с термином, поясни.

> б) Рвать коннект после каждого запроса и устанавливать заново
> дперед следующим

Нафига ? Приложения, они, знаешь ли, подобным поведением не отличаются.

> в) В качестве подопытных таблиц не брать те, у которых 2-
> 3 инт-поля

desc all_objects
Name Null? Type
----------------------------------------- -------- ---------------
OWNER NOT NULL VARCHAR2(30)
OBJECT_NAME NOT NULL VARCHAR2(30)
SUBOBJECT_NAME VARCHAR2(30)
OBJECT_ID NOT NULL NUMBER
DATA_OBJECT_ID NUMBER
OBJECT_TYPE VARCHAR2(19)
CREATED NOT NULL DATE
LAST_DDL_TIME NOT NULL DATE
TIMESTAMP VARCHAR2(19)
STATUS VARCHAR2(7)
TEMPORARY VARCHAR2(1)
GENERATED VARCHAR2(1)
SECONDARY VARCHAR2(1)

Как бы не 2-3 инт поля.

> Про стринги.
> Ты всерьез счиатешь, что серверу пофиг, какое поле обрабатывать
> - числовое или стринговое ..сот байт длиной - на скорости
> выборок это не сказывается

Я считаю, что серверу пофиг, какое поле обрабатывать, лишь бы размер не сильно гулял.
А соединять по стрингам длиной несколько сот байт - ну может задача такая...Всякое бывает.

Впрочем, можем провести еще пару экспериментов.

← →
ANB (2008-05-22 10:34) [48]

> причем не просто стрингов, а всяких там тримов, кастов,
> конвертов и пр. из 10 таблиц.

Ежли 0 записей, то есть вероятность (невеликая), что быстро. А вот если тебе в этой связке нужно посчитать сумму хотя бы по одному полю и ее вернуть и при этом план будет - связки нестед лупсом, то скорее всего первый запрос будет работать намного дольше, чем второй. И еще скорее всего первый запрос завалится по снапшот ту олд.

> Я считаю, что серверу пофиг, какое поле обрабатывать, лишь
> бы размер не сильно гулял.

+1

SQL Найти похожие ветки