6000000 млн.записей или все-таки 6 млн.записей?
мало инфы указал.
Сколько записей под каждое подусловие попадает?
Rik IN(2010,2011)
Ozn IN(1,101)
VAL(Kod) IN(SELECT Kod FROM Zapros)

Сколько всего записей в результате запроса получается?

подозреваю что надо индекс по KOD, только запрос надо немного переделать чтобы индекс заработал. VAL() убрать как-то так:

sys(3054, 2) - выводит как работает оптимизатор. Посмотри какие индексы он берет.
Провел тест:
оптимизируется Rik IN(2010,2011), т.е. для такого условия индекс по Rik он задействует
это НЕ оптимизируется Kod IN (SELECT ..), т.е. будет перебор результата выборки по остальным условиям.

Вобщем для задействования индекса по Kod надо заменять подзапрос на макроподстановку:
генеришь список значений из Zapros в переменную lcZapros и


Тут возможна проблема с длинной запроса в символах, если будут ошибки что запрос слишком длинный, то разбивать на несколько запросов, а потом склеивать результаты.

По выбору индексов ты не сказал что я просил. Сделай такие запросы:


если запрос возвращает много записей, то индекс по этому полю будет бесполезен. Сколько значит "много" точно не скажу, думаю 20-25% от размера исходной таблицы. Если получишь более 50% то такой индекс может даже замедлять запрос.
Чем меньше записей выбирается по конкретному условию для поля тем больший эффект даст индекс по этому полю.

И условия надо расположить по мере убывания эффективности индекса, т.е. например если Ozn IN (1,101) дает наименьшее количество, то его поставить вперед:

ВладимирМDima Tsys(3054, 2) - выводит как работает оптимизатор. Посмотри какие индексы он берет.
Провел тест:
оптимизируется Rik IN(2010,2011), т.е. для такого условия индекс по Rik он задействует
это НЕ оптимизируется Kod IN (SELECT ..), т.е. будет перебор результата выборки по остальным условиям.

Ты не туда смотрел. В данном случае надо "ловить" оптимизацию Join, а не Where. Т.е. нужно sys(3054,12). Оптимизатор показывает, что промежуточный результат объединения использует индекс в подзапросе. Другими словами, нужен индекс по тому полю, которое отбирается в позапросе.
Я туда и не смотрел, не люблю sys(3054), загаживает экран всякими буковками :)
Тут главный тормоз в том что по сетке качается много лишних записей. Это проще всего смотреть диспетчером задач - добавляем колонку "Скачано, байт" и смотрим чего дает каждый вариант. Только для чистоты эксперимента фокс лучше перезапускать перед каждым запросом, чтобы влияние кэша фокса исключить.

Посмотрел с sys(3054,11) и sys(3054,12) - не использует оптимизатор индекс для подзапроса.

А вот переделывание в JOIN дало результат аналогичный выше предложенной макроподстановке. Чего-то не догадался его попробовать в прошлый раз.
Макс_П попробуй такой вариант:


если скорость нормальная будет - лучше его используй чем макроподстановки.

Макс_ПЕсть две таблицы - Т1 и Т2. В таблице Т1 поля а1,а2,...,а20, в таблице Т2 поля а1,а2,...,а5.
Как КРАСИВО и с оптимизацией оставить в базе Т1 только те записи, которых нет в Т2 (интересуют только поля а1-а5)? Структура полей абсолютно одинаковая.
Формулируй задачу правильно. Нет такого действия "оставить".
Правильно понимаю: "Удалить в Т1 записи которые есть в T2" ? Как-то так


но такая конструкция может тормозить, поэтому надежнее условие заменить на такое:


Твои типы полей не знаю, если не символьные - приведи к символьным.

ВладимирМКак-то странно ты смотрел

Нормально смотрел, в отличии от некоторых.
sys(3054,11) выдает:
sys(3054,11)Joining intermediate result and intermediate result using index tag F2
И толку нам от индекса по табличке в 20 записей, когда будет скан 6 млн. записей?

PS Если оптимизатор работал правильно на подзапросах, то все бы порешалось тут

ВладимирМDima Tне использует оптимизатор индекс для подзапроса

Тем не менее, оптимизатор показывает, что индекс используется и именно для подзапроса.
Использует оптимизатор индекс, только не тот какой надо.
Оптимизатор криво работает с подзапросом.

Я считаю это недоделка в оптимизаторе, результат подзапроса всегда меньше таблицы из которой выборка идет.

ВладимирМСобственно, проще было бы провести эксперимент на реальных данных.
Я так и делал, взял свою табличку 50 млн.записей и пробовал запросы с аналогичным синтаксисом. Подзапрос тормозит.
Диспетчер задач это подтверждает у меня: при подзапросе качается 20 Мб, при JOIN и макроподстановке 450 кб.
У Макс_П тоже подзапрос тормозит раз с макроподстановкой стало 2 сек. вместо минуты.

Banditos, не буду комментировать твой пост. В топике речь о конкретном запросе, а не об использовании подзапросов в целом.

BanditosИначе, право, немного странно слышать обсуждение насчет необходимых индексов под "не очень" селекты. Всегда пробовал сначала довести до ума сами селекты...
Так и надо было сразу селекты предлагать, а не общие фразы писать. Не люблю обсуждать сферических коней в вакууме.