Ситуация стандартна до безобразия.
Имеется некая таблица с ~100000 записей (TABLE). В таблице есть некий параметр (PARAM_REF) по которому необходимо сделать выборку. Дык вот запрос с Where

Select count(*) from TABLE Where PARAM_REF = @PARAM_REF


работает на порядок быстрее (т.е. порядка в 9-10 раз), чем запрос с джойном временной таблицы, в которой всего одно поле (PARAM_REF) и одно значение в таблице (=@PARAM_REF)

Select count(*) from TABLE T
join #TMP Tmp on T.PARAM_REF = Tmp.PARAM_REF

Замеры быстродействия производились только на результирующих запросах (т.е. бех учета создания временной таблицы, ее заполнения и т.п.)...

Приэтом. Полностью аналогичная структура на микрософтовском серваке таких разниц в работе не дает...

Вопрос: где собака зарыта? Куда копать? Есть необходимость делать темповую таблицу (так как в преспективе может быть выборка не по одному значению) но нет желания так терять производительность.

cherrex_DenА во временной таблицы записей много? Может надо индекс построить по этому полю во временной таблицы, или явно(forceplan) ее первой поставить!
Но без плана это только дагадки!

Еще раз повторюсь - записей в таблице всего ОДНА. И она равна значению переменной.

Force Plan дал увеличение производительности но не сильно ощутимое (порядка 3-5%)

ПЛАН ЗАПРОСА БЕЗ ВРЕМЕННОЙ ТАБЛИЦЫ
|ROOT:EMIT Operator
|
| |SCALAR AGGREGATE Operator
| | Evaluate Ungrouped COUNT AGGREGATE.
| |
| | |SCAN Operator
| | | FROM TABLE
| | | Card_Order
| | | CO
| | | Using Clustered Index.
| | | Index : Card_Type
| | | Forward Scan.
| | | Positioning by key.
| | | Keys are:
| | | Card_Type_ID ASC
| | | Using I/O Size 2 Kbytes for data pages.
| | | With LRU Buffer Replacement Strategy for data pages.


ПЛАН ЗАПРОСА С ВРЕМЕННОЙ ТАБЛИЦЕЙ:

|ROOT:EMIT Operator
|
| |SCALAR AGGREGATE Operator
| | Evaluate Ungrouped COUNT AGGREGATE.
| |
| | |MERGE JOIN Operator (Join Type: Inner Join)
| | | Using Worktable2 for internal storage.
| | | Key Count: 1
| | | Key Ordering: ASC
| | |
| | | |RESTRICT Operator
| | | |
| | | | |SCAN Operator
| | | | | FROM TABLE
| | | | | Card_Order
| | | | | CO
| | | | | Table Scan.
| | | | | Forward Scan.
| | | | | Positioning at start of table.
| | | | | Using I/O Size 2 Kbytes for data pages.
| | | | | With LRU Buffer Replacement Strategy for data pages.
| | |
| | | |SORT Operator
| | | | Using Worktable1 for internal storage.
| | | |
| | | | |SCAN Operator
| | | | | FROM TABLE
| | | | | #Card_Type
| | | | | CT
| | | | | Table Scan.
| | | | | Forward Scan.
| | | | | Positioning at start of table.
| | | | | Using I/O Size 2 Kbytes for data pages.
| | | | | With LRU Buffer Replacement Strategy for data pages.


P.S. выдергивал через эмбаркодеру, так как родной интеркатив скул послал нафиг сказав, что ему чего-то не хватает, а времени разбираться нет

morisУ вас ошибочно MERGE JOIN используется для join. Как результат большая таблица в отсортированном порядке записывается во временную.


Шаман однако! Спасибо помогло!
Вопрос такой - получается Sybase по умолчанию цепанул Merge Join...
Т.е. желательно все запросы просматривать по плану и если что явно корректировать?

cherrex_DenMikle83,
Ну неудивительно, у вас Table Scan!
индекс "Card_Type" по полю PARAM_REF сделан в таблице TABLE(Card_Order)?

Само собой индекс есть.


cherrex_Den
а если так:
Select count(*) from TABLE T (index Card_Type)
join #TMP Tmp on T.PARAM_REF = Tmp.PARAM_REF
[/quot]
А вот так не пракатывает - ругается на некорректный синтаксис. В принципе проблема решилась вариантом, предложенным moris... Только вот теперь с сомнением смотрю на все остальные запросы/процедуры :)

С синтаксимос разобрался - но работать стало даже чуть-чуть дольше...

Проверил - все связующие поля идентичны по типам (numeric(18))