glamisSergey Sizov,

Мне теперь для каждой выборки строить свои индексы? Можете построить чужие. Вам решать что для вас важнее - скорость работы программы, место на диске или ваша лень.В таблице около 30 полей и что, по каждому строить индекс? Стандартный идиотский вопрос... Откуда взялось слов "все"? Вроде я показал, что индексы нужны по выражениям в предложении where? Если нет, то откуда "все"?
К тому же, индексы именно для ускорения выполнения запросов и создаются, а не "абы были". И под конкретные запросы, а не абы какие. Под предложенный вами запрос нужны такие.Насчет кеширования - только что сбросил таблицу по сетке на другой ресурс, с другим именем и сделал выборку в другой сессии fox - МГНОВЕННО.Из чего можно сделать вывод, что дело, скорее всего не в бобине. Как минимум не в кэшировании. Проверяйте остальное окружение.

Dima TSergey SizovСударь, вы думаете я это в текстовом редакторе написал? Вам показать код, который выводит сие сообщение? Извольте.
...
Потом расскажете про использование только одного индекса.
"На заборе тоже написано, а забором нету!" (с)

Я утверждаю что "Rushmore optimization level for intermediate result: full" не означает "Найдено наилучшее решение".
При некоторых обстоятельствах решение может оказаться наихудшим.Угу. Например, на маленькой таблице, где накладные расходы на индексы могут превысить достигнутый результат ускорения. Или ошибки в движке, которые правились сервиспаками. Ну и т.д.
Я однажды наступал на подобные грабли, запрос был похожий


таблица открыта локально, монопольно, записей прядка 100+ млн. индексы были оба по f1 и f2, но в один прекрасный день этот запрос завесил проц на 100% и завершения я не дождался. Последующие проверки зависание повторяли, переиндексация не помогала. Помогла смена индекса на str(f1) + str(f2)А тут сразу всплывает версия самого фокса и его сервспаков. :)
PS Пища для размышлений: почему MS SQL никогда не использует два индекса?А там индексы не по выражениям. И используются, в том числе, ВМЕСТО данных из таблицы. Поразмышляйте на досуге.

Dima T,
должно быть 09.00.0000.7423

glamisSergey Sizov,
На таблице висит 200 юзеров. Как ты себе ты представляешь такое взрослое решение как индексация когда захочуГде, кто и когда такое предлагал? Плюнь тому в морду. :) (при этом она тоже требует времени) или работа такого кол-ва юзеров по обновлению 30 индексов?И опять двадцать пять... Какие еще 30 индексов? Мне требуется исполнение скрипта в пределах 10-15 сек, а тут одна из операций сжирает 25, а общее время вылетает под 100.Ну прям америку открыл, а мужики то и не знают... Ну так разбирайся почему так, чего тут ныть?
Переиндексация, в общем-то, обслуживающая процедура и не должна проводится в рабочее время. Неужели первый раз об этом слышишь?

Вопрос на самом деле почему выборка в одной копии таблицы происходит мгновенно, а в другой - достаточно долго.
Сейчас скопировал исходную таблицу вместе с cdx. Сделал ее свободной. Выборка - долго. Переиндексировал - долго.Вопрос про сферического коня. Все зависит от твоей конкретики, которую тут никто не видит и может только гадать. Гадания тебе выдали.

glamis,

наше дело предложить, ваше дело не воспользоваться нашим предложением. Успехов в гаданиях.

Dima T,
нет там ничего страшного ибо там только DLL, которые надо руками разложить в нужные места.

glamisasdor,
Дело в том, что выбор идет по полю oper с дополнительным фильтром empt(uslov), а Sergey Sizov советует для ускорения создать и индекс по uslov.Точно-точно? А если внимательнее перечитать? Но выборки бывают с разными фильтрами,Какая неожиданная новость! те для каждой выборки, по этой логике, нужен свой дополнительный индекс.По какой ТАКОЙ логике? Если все время утверждалось, что индексы нужны по выражениям в условиях отборов? Типа выражения там никогда не повторяются? А как быть с таким индексом, если требуется empt(uslov), !empt(uslov),Эти два условия покрываются 1(Одним) индексом. uslov='12345'. Это ведь тоже разные индексы для оптимизатора.Разумеется. А вы, как я понимаю, хотите обойтись одним-двумя? На каком основании?
1-я копия действительно урезана. Она меньше тыс. на 2 удаленных записей, при общем объеме 5500000. Получилась командой Copy to.

Тут фишка в том, что если делать выборку where oper='007001', то в обоих случаях выборка происходит мгновенно, точнее не выборка а какой-то именованный фильтр.То есть про способ выполнения запросов путем наложения хитрого фильтра вы не знаете. При этом recc() показывает количество записей в исходной таблице, а count количество записей в выборке. При попытке сделать Select из такой выборки система выдает ошибку и предлагает использовать форму into table для первоначальной выборки. Помогает Nofiltr, но при этом время выборки резко возрастает.Ибо не используются кэшированные данные и происходит физическая переливка данных в новый курсор Это к чему - для копии таблицы по такой же схеме срабатывает и where oper = '007001' and !empt(uslov), а для исходной не срабатывает. Кто на ком стоял?
Вот вопрос и был - ПОЧЕМУ. а Sergey Sizov пытался рассказать КАК можно сделать. КАК можно я и сам знаю. Сейчас время срабатывания 0.1сек, но решение-то не системное...Интересно, как можно было что-то рассказать по поводу "почему?" если очень важная для этого информация только сейчас опубликована?
Да, какое решение несистемное? Создание индексов?

glamisDima T,

У меня SP3 стоит. По-крайней мере должна стоять:)Для фокса нет такого сервис пака. Последнее что было и имело указанную мной версию, был хот фикс к SP2.