powered by simpleCommunicator - 2.0.59     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Caché, Ensemble, DeepSee, MiniM, IRIS, GT.M [игнор отключен] [закрыт для гостей] / Оптимизация запроса
12 сообщений из 12, страница 1 из 1
Оптимизация запроса
    #35548004
CJIECAPb
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Имеется запрос следующего вида,
Код: plaintext
1.
2.
SELECT TOP  300  Поле1 FROM Таблица1
WHERE ID IN (SELECT Поле2 FROM Таблица2 WHERE Поле3= 1 )
По плану запроса видно, что Cache бегает по всем записям "Таблица1" и для каждой из них выполняет подзапрос, хотя он возвращает список всего из нескольких ID. Как заставить оптимизатор сначала выполнять подзапрос, а потом уже по его результату выбирать нужные поля из "Таблица1"?

$SYSTEM.SQL.TuneTable на "Таблица1" и "Таблица2", а так же %FULL, %INORDER, %NOSVSO и %NOFLATTEN не помогают. При этом если убрать из запроса "TOP 300" он начинает работать так как хотелось бы, но надо заставить нормально работать именно исходный запрос....
...
Рейтинг: 0 / 0
Оптимизация запроса
    #35548017
Фотография krvsa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
А если так...


Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
SELECT 
   T1.Поле1 
FROM 
   Таблица1 T1,
   Таблица2 T2
WHERE 
   T1.ID=T2.Поле2
   AND
   T2.Поле3= 1 
----------
Cache for Windows (x86-32) 2007.1.3 (Build 607) Wed Oct 17 2007 02:12:09 EDT
...
Рейтинг: 0 / 0
Оптимизация запроса
    #35548019
Блок А.Н.
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Не верю, приведите план.
...
Рейтинг: 0 / 0
Оптимизация запроса
    #35548024
Блок А.Н.
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
верю
...
Рейтинг: 0 / 0
Оптимизация запроса
    #35548056
CJIECAPb
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
krvsaА если так...


Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
SELECT 
   T1.Поле1 
FROM 
   Таблица1 T1,
   Таблица2 T2
WHERE 
   T1.ID=T2.Поле2
   AND
   T2.Поле3= 1 
----------
Cache for Windows (x86-32) 2007.1.3 (Build 607) Wed Oct 17 2007 02:12:09 EDT
хм
канает даже если добавить TOP
...
Рейтинг: 0 / 0
Оптимизация запроса
    #35548308
Фотография krvsa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Т.е. быстрее работает?

ТОП я просто не стал писать...
----------
Cache for Windows (x86-32) 2007.1.3 (Build 607) Wed Oct 17 2007 02:12:09 EDT
...
Рейтинг: 0 / 0
Оптимизация запроса
    #35548423
Ptn
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Вообще план то у запроса вполне ожидаемый...

c IN у каше традиционно не хорошо

Другое дело что размеры таблицы1 и таблицы2 какие по объему записей
...
Рейтинг: 0 / 0
Оптимизация запроса
    #35552094
Блок А.Н.
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Столкнулся с похожей проблемой при апдейте

Код: plaintext
1.
2.
3.
UPDATE  Таблица1
SET Поле1=(..)
WHERE Поле1 IN (SELECT ID FROM Таблица2)

Поле1 индексированое.
По плану, если я не ошибаюсь, запрос идет по индексу Поле1, проверяет наличие значения в Таблице2.

Дело в том, что Таблица1 огромная и даже проход по индексу занимает слишком много времени, а таблица2 очень маленькая.

Нужно чтобы запрос шел по Таблице2, обновлял найденные значения в таблице1

Как научить оптимизатор идти по нужному пути?
Пока из идей только сделать цикл по таблице2 и вручную обновлять поля в таблице1, но это слишком тупо.
...
Рейтинг: 0 / 0
Оптимизация запроса
    #35552210
Фотография krvsa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ммм, дааа с UPDATE сложнее чем с SELECT... Тут табличка явно указана.
----------
Cache for Windows (x86-32) 2007.1.3 (Build 607) Wed Oct 17 2007 02:12:09 EDT
...
Рейтинг: 0 / 0
Оптимизация запроса
    #35552462
CJIECAPb
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Блок А.Н.Столкнулся с похожей проблемой при апдейте

Код: plaintext
1.
2.
3.
UPDATE  Таблица1
SET Поле1=(..)
WHERE Поле1 IN (SELECT ID FROM Таблица2)

Поле1 индексированое.
По плану, если я не ошибаюсь, запрос идет по индексу Поле1, проверяет наличие значения в Таблице2.

Дело в том, что Таблица1 огромная и даже проход по индексу занимает слишком много времени, а таблица2 очень маленькая.

Нужно чтобы запрос шел по Таблице2, обновлял найденные значения в таблице1

Как научить оптимизатор идти по нужному пути?
Пока из идей только сделать цикл по таблице2 и вручную обновлять поля в таблице1, но это слишком тупо.

Как вариант можно сначала выполнить
Код: plaintext
SELECT ID FROM Таблица2
а потом подставить в исходный запрос уже явный список (ID1,ID2,...)
Если запрос выполняется в рамках программы каше, можно сделать $LB() результатов подзапроса и выполнить
Код: plaintext
1.
2.
3.
UPDATE  Таблица1
SET Поле1=(..)
WHERE Поле1 %INLIST :List
...
Рейтинг: 0 / 0
Оптимизация запроса
    #35552514
Фотография krvsa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Так оно может опять будет все ИД перебирать
----------
Cache for Windows (x86-32) 2007.1.3 (Build 607) Wed Oct 17 2007 02:12:09 EDT
...
Рейтинг: 0 / 0
Оптимизация запроса
    #35552515
Блок А.Н.
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Хм, таблица2 все-таки не настолько маленькая, порядка полутясячи записей.
Просто таблица1 может быть больше сотни миллионов записей.

Вроде в этом случае придумал как выкрутиться, пойду по другим индексам.
...
Рейтинг: 0 / 0
12 сообщений из 12, страница 1 из 1
Форумы / Caché, Ensemble, DeepSee, MiniM, IRIS, GT.M [игнор отключен] [закрыт для гостей] / Оптимизация запроса
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]