Простой запрос

SELECT док.IDDOC
FROM $Документ.Заявка_шапка док, _1sjourn j
WHERE j.iddoc = док.IDDOC
AND j.DOCNO = 'al-90022'
AND j.actcnt > 0

выполняется секунд 30-40, имеем index scan по индексу DOCNO (стандартный 1сный)

select count(*) from _1sjourn == 1580192

Что можно сделать для ускорения?
Ну, разумеется, кроме перестройки индекса :-)

(0) это же не весь запрос ?

(1) Ты не поверишь :-) Весь.

(0) А период известен?
В индексе по DOCNO используется DNPREFIX

DNPREFIX
Назначение:
Префикс номера документа. Тип - Строка(18). Для документов, у которых код числовой это поле равно десятичному ID вида документа. Если нумерация в пределах преиода - то также храниться и период в виде ГГГГММДД (например 2006 для нумерации в пределах года).

(3) В том-то и фича, что нужно вне зависимости от периода... Иначе обошёлся бы простым НайтиПоНомеру

(2) нафига тогда там $Документ.Заявка_шапка уперлась?

(4) А ты попробуй условие всё ж таки добавь

(5) А я сам сейчас сижу и думаю, зачем :-)
Наверное, чтобы ограничить поиск только заявками
Когда писал это, был слабовсебяем :-)
Хотя пробовал добаить условие на iddocdef, без заявки - всё одно.

(6) С условием-то работает нормально. Но мне что, все периоды перебирать?
А с like работает ещё медленней

(8) А что их много? годов то?

(9) Ну, штуки 4 уже есть...

(10) Всё равно быстрее будет.

(11) А через 10 лет? :-)
Ну, я пока индексами обошёлся, всё равно база работает 24х7, и задание на создание допиндексов есть...

не вкурю..
вот так не устраивает ?

SELECT
   Жур.IDDoc as [Док $Документ],
   Жур.IDDocDef as Док_вид
FROM
 _1SJourn as Жур
WHERE
  Жур.DocNo = 'al-90022' and Жур.IDDocDef  = $ВидДокумента.Заявка_шапка

(13) Пробовал. План запроса практически такой же. Индекс скан.

А статистику не пробовали обновить?

(15) Даже индекс перестраивал :-)

(16) не, это вам вряд ли бы помогло.. А какое соотношение [количество возвращаемых записей]/[общее количество записей в таблице]? Я правильно понимаю, что возвращается только одна запись (сорри, как 7.7 хранит данные даже не представляю)?

(17) соотношение 1 к 1580192 :-)
Ну может, не 1, а больше, но не 50%. Обычно от 1 до 10.

тогда это очень (прямо очень-очень-очень) сильно похоже на неправильную статистику.. А сканируемый индекс строится только по одному полю IDDoc? Если нет - оно в этом индексе первое?

(19) в смысле DocNo

(19) Нет и нет :-)
Это я и сам знаю...

(21) ну так, если у вас нет подходящего индекса - как же вы хотите добиться Index Seek?

(22) Да я всё понимаю :-)

хм.. окей (:

попробуй такую конструкцию:

and j.DOCNO <= 'al-90022' and j.DOCNO >= 'al-90022'

мне помогло при переходе с sql2000 на sql2005 на аналогичной базе

(25) неа...

Для попадания в индекс надо задать dnprefix
Шапка Заявка вообще не нужна только напрягаешь оптимизатор запросов
dnprefix - значение завимит от переодичность по виду документа.
Если нумерация в пределах года то надо объеденить 4 запроса через union all

SELECT
   Жур.IDDoc,Жур.dnprefix
FROM
_1SJourn as Жур
WHERE
 Жур.DocNo = '18311' and Жур.IDDocDef  = 196
and   Жур.dnprefix = '       1962010    '  
union all
SELECT
   Жур.IDDoc,Жур.dnprefix
FROM
_1SJourn as Жур
WHERE
 Жур.DocNo = '18311' and Жур.IDDocDef  = 196
and   Жур.dnprefix = '       1962009    '

PS (как то не совсем так написал )
Если надо данные за 4 года то надо объеденить 4 запроса через
union all

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

это 1с++ хреновит, в прямую при 250000 отрабатывает максимум за 0.1

(29) Очень смешно. План запроса я тоже через 1с++ смотрел?

(30) х.з. ))
но ведь отрабатывает не за 30 сек

(30) а скуль то какой у тебя ?, у меня на пол ляма обычный поиск милисекунды работает..

(32) 2005й.

(33)не. у меня по старинке ,2000
надо бы тоже погонять, на 2005/2008..

(0) А так?
SELECT док.IDDOC
FROM $Документ.Заявка_шапка док
JOIN _1sjourn j ON j.iddoc = док.IDDOC
WHERE j.DOCNO = 'al-90022' AND j.actcnt > 0

(35) а зачем там табличка документа сдалась ? :)

(35) да это то же самое

(37) Я знаю. Пробовал?

(38) ПРобовал. План запроса совершенно аналогичен

ыыы... а (NOLOCK) не нужен и SET NOCOUNT ON?

(40) Нолок не помешал бы, но пока не мешает. нокаунт не нужен. Это ж не триггер.

Как-то подозрительно долго даже для полного перебора полутора лямов записей...
ИМХО, если добиться сканирования по кластерному индексу - будет в разы быстрее.

(41) (NOLOCK) воткни

Да ладно, Дениска просто небось прикалывается.

SQL 2005 кэширует планы запросов. Первый запрос всегда медленно. Остальные - быстро.

(45) ну не 30 же секунд..

Может, фрагментация индекса сильная? Или у сервака проблемы с ресурсами?

(46) 10-15 секунд для любого запроса в первый раз всегда.

(48) обожаю категоричные высказывания.
Сказал, как отрезал.
Даже "у меня" не добавил.

(0)
1. Если убрать "AND j.actcnt > 0", план останется прежним?
2. Если 'al-90022' дополнить пробелами до длины DOCNO, план останется прежним?

(49) ОК - у меня :)    SQL-2005 Express на разных серверах (разных филиалах).

select IDDoc, docno
from _1SJourn (nolock)
выполняется ~ 2 сек, результат 430204 доков

select IDDoc, docno from _1SJourn (nolock)
where iddocdef = 1611
выполняется ~ 2 сек, результат 37615 доков

select IDDoc, docno
from _1SJourn (nolock)
where iddocdef = 1611 and docno = 'Т000000541'
выполняется < 1сек. результат 3 дока

+52
база комплексная скуль 2000-й

+53
кстати ИНДЕКС СКАН

(53) у автора 2005, если что..

(51) Выноси свою проблему в отдельную ветку, детально описывай, и не делай больше скоропалительных выводов. А то оказывается сиквел меньше десяти секунд план запроса не составляет. А хлопцы-то и не знают...
Пока могу попробовать телепатировать, что дисковая подсистема у тебя везде отнюдь не серверная. Поэтому в первый раз выборки у тебя так долго и формируются. А на повторных кэш ДАННЫХ сиквела рулит (а не плана запроса).
Или у тебя "SELECT 'Вася'" тоже 15 секунд план запроса конструирует?

(55) я когда повыше прочитал...и уточнил что у меня
(53)

(50) да и да

(56) Да ты не кипятись. У меня проблемы нет, чтобы выносить в отдельную ветку. Я всего лишь пытался подсказать автору одно из возможных объяснений. Кстати, ты прав, подсистема у меня действительно не серверная. А где написано, что у автора не так?

(58) А явное указание dnprefix в запросе?

+(60) Снимаю вопрос, не заметил (4)

укажите отбор по полю "DNPREFIX"
тогда будет индексированный поиск

никогда на это поле внимания не обращал.
вроде оно состоит из id нумератора и года

если указать это поле (с годами) скорость выборки (закешированной) в smss = 0.

доков в базе ~4 850 000.

(62) я вроде чётко задачу свою объяснил...

(63) Денис, я поэкспериментировал.
Если в запросе указать дополнительно DNPREFIX<>'' - получается INDEX SEEK

(64) именно не равно пустое строке? Надо будет проверить....

(64) аналогично, только время запроса уменьшилось ненамного.. (2000 скуль)

(63)
так я Вам и указал что поле состоит из ид отбора и года
так что уазав

where DNPREFIX >= '       296       '
and  DNPREFIX >= '       298       '

,где ид отбора 287
Вы обстрагируетесь от года

+67
читать вместо 287 =297

(65) Именно. Этим мы принуждаем SQL использовать SEEK. Старый трюк.

(67) вот теперь понял. Проверим

(69) Ни разу не встречал..

(71) ты там потом кинь результаты замеров..

(72) завтра утром, меня тут поднапрягли, некогда пока всё проверять.

(0)Не, ну если тебе нужны сики, то пробуй так:

SELECT
   док.IDDOC
FROM $Документ.Заявка_шапка as док (NOLOCK)
INNER JOIN _1sjourn as j (NOLOCK) ON j.iddoc = док.IDDOC
WHERE
   j.row_id IN (SELECT row_id FROM _1sjourn (NOLOCK) WHERE dnprefix != '' AND docno LIKE 'al-90022')
   AND j.actcnt > 0

(41)Назначение хинта NOLOCK понимаешь в полном объеме?

Так чем закончилось ? Мы же следим

некогда пока
(74) да, понимаю.

(76)сомневаюсь, что понимаешь в полном объеме.

(77) Это твоё право...

я в (74) слегка погорячислся с таким dnprefix != '', наверно, следует заменить на dnprefix >= ''

(79) да и как в (64) работает.

(80)ну тут принципиальное решение, а вдруг кто-то в этом поле '' пропишет.

После экспериментов получилось, что
and j.dnprefix > '     15124'
наиболее эффективно.
Всем спасибо.

(82) ну ты как маленький.. время то какое теперь ?
Слово "эффективней" - это пустой звук, по сравнению с 30-40 секундами.

(83) точно подсчитать не могу, но разница раза в 3

агуеть

(82) не получается.
ни теоретически - попробуй убеди меня почему мы в этом случае должны попадать в индекс.(хотя и виду план запроса в qa)
ни практически. тесты приводяться ниже.

Тесты запускал так.
Все тесты выполнялись в qa.
С одного компьютера.
Каждый запрос(тест) выполнял по три раза.
Перед каждым стартом запроса делал очистку кеша процедур
и очистку буфера данных.

тест №1

SELECT
   Жур.IDDoc,Жур.dnprefix
FROM

_1SJourn as Жур
WHERE
 Жур.DocNo = '18311' and Жур.IDDocDef  = 196
and   Жур.dnprefix > '       1962004    '


тест №2

SELECT
   Жур.IDDoc,Жур.dnprefix
FROM

_1SJourn as Жур (nolock)
WHERE
 Жур.DocNo = '18311' and Жур.IDDocDef  = 196
and   Жур.dnprefix > '       1962004    '

тест №3


SELECT
   Жур.IDDoc,Жур.dnprefix
FROM

_1SJourn as Жур
WHERE
 Жур.DocNo = '18311' and Жур.IDDocDef  = 196
and   Жур.dnprefix = '       1962004    '
union all
SELECT
   Жур.IDDoc,Жур.dnprefix
FROM

_1SJourn as Жур
WHERE
 Жур.DocNo = '18311' and Жур.IDDocDef  = 196
and   Жур.dnprefix = '       1962005    '
union all
SELECT
   Жур.IDDoc,Жур.dnprefix
FROM

_1SJourn as Жур
WHERE
 Жур.DocNo = '18311' and Жур.IDDocDef  = 196
and   Жур.dnprefix = '       1962006    '
union all
SELECT
   Жур.IDDoc,Жур.dnprefix
FROM

_1SJourn as Жур
WHERE
 Жур.DocNo = '18311' and Жур.IDDocDef  = 196
and   Жур.dnprefix = '       1962007    '
union all
SELECT
   Жур.IDDoc,Жур.dnprefix
FROM

_1SJourn as Жур
WHERE
 Жур.DocNo = '18311' and Жур.IDDocDef  = 196
and   Жур.dnprefix = '       1962008    '
union all
SELECT
   Жур.IDDoc,Жур.dnprefix
FROM

_1SJourn as Жур
WHERE
 Жур.DocNo = '18311' and Жур.IDDocDef  = 196
and   Жур.dnprefix = '       1962009    '
union all
SELECT
   Жур.IDDoc,Жур.dnprefix
FROM

_1SJourn as Жур
WHERE
 Жур.DocNo = '18311' and Жур.IDDocDef  = 196
and   Жур.dnprefix = '       1962010    '

тест №4


SELECT
   Жур.IDDoc,Жур.dnprefix
FROM

_1SJourn as Жур (nolock)
WHERE
 Жур.DocNo = '18311' and Жур.IDDocDef  = 196
and   Жур.dnprefix = '       1962004    '
union all
SELECT
   Жур.IDDoc,Жур.dnprefix
FROM

_1SJourn as Жур  (nolock)
WHERE
 Жур.DocNo = '18311' and Жур.IDDocDef  = 196
and   Жур.dnprefix = '       1962005    '
union all
SELECT
   Жур.IDDoc,Жур.dnprefix
FROM

_1SJourn as Жур  (nolock)
WHERE
 Жур.DocNo = '18311' and Жур.IDDocDef  = 196
and   Жур.dnprefix = '       1962006    '
union all
SELECT
   Жур.IDDoc,Жур.dnprefix
FROM

_1SJourn as Жур  (nolock)
WHERE
 Жур.DocNo = '18311' and Жур.IDDocDef  = 196
and   Жур.dnprefix = '       1962007    '
union all
SELECT
   Жур.IDDoc,Жур.dnprefix
FROM

_1SJourn as Жур  (nolock)
WHERE
 Жур.DocNo = '18311' and Жур.IDDocDef  = 196
and   Жур.dnprefix = '       1962008    '
union all
SELECT
   Жур.IDDoc,Жур.dnprefix
FROM

_1SJourn as Жур  (nolock)
WHERE
 Жур.DocNo = '18311' and Жур.IDDocDef  = 196
and   Жур.dnprefix = '       1962009    '
union all
SELECT
   Жур.IDDoc,Жур.dnprefix
FROM

_1SJourn as Жур  (nolock)
WHERE
 Жур.DocNo = '18311' and Жур.IDDocDef  = 196
and   Жур.dnprefix = '       1962010    '

Тест1 №1 отличается от теста №2 наличием nolock
Тест1 №3 отличается от теста №4 наличием nolock

Результаты в секундах ( то что показывает qa )
тест № 1   28  35  15
тест № 2   16  23  19
тест № 3   1   10  4
тест № 4   0   1   1

Все тесты естественно вернули одно и тоже количество строк ( четыре )
При выполнении более старших тестов общее число документов могло только увеличиваться.

всеравно не понял откудова там десятки секунд

(93) база колбаситься сильно -  ожидание окончания  блокировок

если надо могу прогнать тесты вечером когда никто не будет работать
т.е. в этом случае должно быть
тест1 = тест2
и
тест3 = тест4

(91) это на каком скуле ? 2000/2005 ?..

(96) sql200 sp3a
если надо то могу прогнать и на sql2005 только в той базе не будет
рабочей нагрузки т.е. как юы ночной режим.

сорри за незначительные опечатки как-то непривычно что нельзя отредактировать свои посты.

(97) а такой что кажет ?
SELECT
   Жур.IDDoc,Жур.dnprefix
FROM
_1SJourn as Жур (nolock)
WHERE
 Жур.dnprefix<>'' and Жур.DocNo = '18311' and Жур.IDDocDef  = 196

тест № 5
SELECT
   Жур.IDDoc,Жур.dnprefix
FROM
_1SJourn as Жур (nolock)
WHERE
Жур.dnprefix<>'' and Жур.DocNo = '18311' and Жур.IDDocDef  = 196


Результаты тест №5  19   20   14

То же не вижу в тест №5 попадания в индекс.
Может по каким-то причинам удается ввести оптимизатор запросов в заблуждение
но потом при выпонении предполагаемый и реальный план могут отличаться.

(101) ну и для чистоты эксперимента:
тест № 6
SELECT
   Жур.IDDoc,Жур.dnprefix
FROM
_1SJourn as Жур (nolock)
WHERE
Жур.DocNo = '18311' and Жур.IDDocDef  = 196

ниче не понимаю, со всеми преобразованиями

declare @start as datetime
declare @count as int
set @start=CURRENT_TIMESTAMP
set @count=(SELECT count(*) /* Жур.IDDoc,Жур.dnprefix*/ FROM _1SJourn as Жур WHERE Жур.DocNo like 'ВЫП%' and Жур.IDDocDef  = 1199)
select @count,'==',datediff(ms,@start,CURRENT_TIMESTAMP)

2043    ==    186

хотя база тормозная (вернее сама конфа )) )

(104) без коментариев
и причем тут конфа когда запускаю из qa
тесты приведены
общая тенденция будет на любой базе

select count(*) from _1SJourn
5,328,544

(105) согласен, что база больше в 10 раз, но даже на 500 тыщах, выходить 200 миллисекунд

за тенденцию спасибо конечно

тест № 6
SELECT
   Жур.IDDoc,Жур.dnprefix
FROM
_1SJourn as Жур (nolock)
WHERE
Жур.dnprefix<>'' and Жур.DocNo = '18311' and Жур.IDDocDef  = 196


Результат тест № 6    13   10  16

(108) неплохо.. даже без доп фильтра быстрее (1,2) :)

объясните для тупых и алкоголиков откудова секунды набегают ?!

(109) народ уже повалил с работы поэтому нельзя сказать что
нагрузка та же самая.

(110) я не ставил задачу точно измерять время
время выдает qa в нижней строке ( в своей строке состояния )
как считает время qa я не знаю.

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

(110) Если не очишить буфер данных и кеш процедур  то даже тест № 6
при втором и следующих выполнениях дает 0  1 0 1 1 0   0

(109)  >>>> неплохо.. даже без доп фильтра быстрее (1,2) :)
да оно и понятно добавив какое то "тупое" условие  dnprefix<> "" хотим попасть в индекс - это фантастика.

(115) да, но в плане запроса видим index seek, заместо index scan

(116) <<<да, но в плане запроса видим index seek, заместо index scan>>>

Это как раз я тоже не понимаю почему.могу повторить только (101)
Может по каким-то причинам удается ввести оптимизатор запросов в заблуждение
но потом при выпонении предполагаемый и реальный план могут отличаться.

вы бы еще, кроме битвы за попадание в индекс, изучили селективность.

(117) а чего покажет запрос (74)?

+119 адаптированный вариант

SELECT
  j.IDDoc, j.dnprefix
FROM _1sjourn as j (NOLOCK)
WHERE
   j.row_id IN (SELECT row_id FROM _1sjourn (NOLOCK) WHERE dnprefix >= '' AND docno LIKE 'al-90022')
   AND j.actcnt > 0

точнее, давай так:

DBCC DROPCLEANBUFFERS
DBCC FREEPROCCACHE
go

SET STATISTICS IO ON
SET STATISTICS TIME ON

SELECT
  j.IDDoc, j.dnprefix
FROM _1sjourn as j (NOLOCK)
WHERE
   j.row_id IN (SELECT row_id FROM _1sjourn (NOLOCK) WHERE dnprefix >= '' AND docno LIKE 'al-90022')
   AND j.actcnt > 0

SET STATISTICS TIME OFF
SET STATISTICS IO OFF
go

Тест № 7
SELECT
  j.IDDoc, j.dnprefix
FROM _1sjourn as j (NOLOCK)
WHERE
   j.row_id IN (SELECT row_id FROM _1sjourn (NOLOCK) WHERE dnprefix >= ''
AND docno like '8311')
and j.IDDocDef  = 196
and j.docno =  '8311'


Результат тест № 7     18  20  21

давай ты покажешь время, выданное скулем на закладке messages?

(123) команды
DBCC DROPCLEANBUFFERS
DBCC FREEPROCCACHE
go

SET STATISTICS IO ON
SET STATISTICS TIME ON
SELECT
  j.IDDoc, j.dnprefix,j.docno,j.IDDocDef

FROM _1sjourn as j (NOLOCK)
WHERE
   j.row_id IN (SELECT row_id FROM _1sjourn (NOLOCK) WHERE dnprefix >= '' AND docno like '18311')
and j.IDDocDef  = 196
and j.docno =  '18311'

SET STATISTICS TIME OFF
SET STATISTICS IO OFF

Messages

SQL Server Execution Times:
  CPU time = 0 ms,  elapsed time = 0 ms.

(4 row(s) affected)

Table '_1SJOURN'. Scan count 15, logical reads 27091, physical reads 570, read-ahead reads 26977.

SQL Server Execution Times:
  CPU time = 1234 ms,  elapsed time = 22125 ms.

Характеристики таблицы                
_1SJOURN
Число строк   5,328,643
Используемое пространство в килобайтах
Всего    1,382,304
Данные    536,384
Индексы   829,704
Свободно   16,216

ну и для порядка: dbcc show_statistics (_1sjourn, docno)

May 27 2010  5:20AM    5323319    71309    180    0.0    37.0

5.5555557E-3    18.0    DNPREFIX
1.9435591E-7    33.0    DNPREFIX, DOCNO
1.8785273E-7    37.0    DNPREFIX, DOCNO, ROW_ID



       422002        0.0    160.0    0    0.0
       422003        9.9447511E-2    720.0    0    74.651436
       422004        9.9447511E-2    80.0    0    74.651436
       422005        9.9447511E-2    80.0    0    74.651436
       422006        9.9447511E-2    240.0    0    74.651436
       422007        9.9447511E-2    240.0    0    74.651436
       422008        9.9447511E-2    400.0    0    74.651436
       422009        9.9447511E-2    614.0    0    74.651436
       422010        9.9447511E-2    187.0    0    74.651436
      1872003        9.9447511E-2    480.0    0    74.651436
      1872004        9.9447511E-2    80.0    0    74.651436
      1872005        9.9447511E-2    160.0    0    74.651436
      1872006        9.9447511E-2    160.0    0    74.651436
      1872007        9.9447511E-2    480.0    0    74.651436
      1872008        9.9447511E-2    720.0    0    74.651436
      1872009        9.9447511E-2    383.0    0    74.651436
      1872010        9.9447511E-2    175.0    0    74.651436
      1962002        9.9447511E-2    160.0    0    74.651436
      1962003        9.9447511E-2    880.0    0    74.651436
      1962004        9.9447511E-2    1040.0    0    74.651436
      1962005        9.9447511E-2    2880.0    0    74.651436
      1962006        9.9447511E-2    2612.0    0    74.651436
      1962007        9.9447511E-2    3308.0    0    74.651436
      1962008        9.9447511E-2    3838.0    0    74.651436
      1962009        9.9447511E-2    4380.0    0    74.651436
      1962010        9.9447511E-2    1984.0    0    74.651436
      2392006        9.9447511E-2    80.0    0    74.651436
      2392007        9.9447511E-2    1.0    0    74.651436
      2392009        9.9447511E-2    171.0    0    74.651436
      2392010        9.9447511E-2    11.0    0    74.651436
      2972004        9.9447511E-2    80.0    0    74.651436
      2972005        9.9447511E-2    160.0    0    74.651436
      2972007        9.9447511E-2    161.0    0    74.651436
      2972008        9.9447511E-2    240.0    0    74.651436
      2972009        9.9447511E-2    343.0    0    74.651436
      2972010        9.9447511E-2    65.0    0    74.651436
      3222004        9.9447511E-2    320.0    0    74.651436
      3222005        9.9447511E-2    160.0    0    74.651436
      3222006        9.9447511E-2    80.0    0    74.651436
      3222007        9.9447511E-2    240.0    0    74.651436
      3222008        9.9447511E-2    240.0    0    74.651436
      3222009        9.9447511E-2    410.0    0    74.651436
      3222010        9.9447511E-2    87.0    0    74.651436
      3362003        9.9447511E-2    320.0    0    74.651436
      3362005        9.9447511E-2    160.0    0    74.651436
      3362006        9.9447511E-2    80.0    0    74.651436
      3362007        9.9447511E-2    160.0    0    74.651436
      3362008        9.9447511E-2    160.0    0    74.651436
      3362009        9.9447511E-2    240.0    0    74.651436
      3362010        9.9447511E-2    71.0    0    74.651436
      3552002        9.9447511E-2    80.0    0    74.651436
      3552003        9.9447511E-2    640.0    0    74.651436
      3552004        9.9447511E-2    560.0    0    74.651436
      3552005        9.9447511E-2    880.0    0    74.651436
      3552006        9.9447511E-2    880.0    0    74.651436
      3552007        9.9447511E-2    1521.0    0    74.651436
      3552008        9.9447511E-2    1517.0    0    74.651436
      3552009        9.9447511E-2    2346.0    0    74.651436
      3552010        9.9447511E-2    677.0    0    74.651436
      3812002        9.9447511E-2    80.0    0    74.651436
      3812003        9.9447511E-2    160.0    0    74.651436
      3812005        9.9447511E-2    80.0    0    74.651436
      3812006        9.9447511E-2    249.0    0    74.651436
      3812007        9.9447511E-2    354.0    0    74.651436
      3812008        9.9447511E-2    160.0    0    74.651436
      3812009        9.9447511E-2    209.0    0    74.651436
      3812010        9.9447511E-2    135.0    0    74.651436
      6492002        9.9447511E-2    80.0    0    74.651436
      6492009        9.9447511E-2    1.0    0    74.651436
      8442003        9.9447511E-2    80.0    0    74.651436
      8442005        9.9447511E-2    160.0    0    74.651436
      8442006        9.9447511E-2    400.0    0    74.651436
      8442007        9.9447511E-2    160.0    0    74.651436
      8442008        9.9447511E-2    160.0    0    74.651436
      8442009        9.9447511E-2    259.0    0    74.651436
      8442010        9.9447511E-2    54.0    0    74.651436
     13902008        9.9447511E-2    80.0    0    74.651436
     13902009        9.9447511E-2    20.0    0    74.651436
     13902010        9.9447511E-2    8.0    0    74.651436
     14992004        9.9447511E-2    320.0    0    74.651436
     14992005        9.9447511E-2    160.0    0    74.651436
     14992006        9.9447511E-2    318.0    0    74.651436
     14992007        9.9447511E-2    80.0    0    74.651436
     14992008        9.9447511E-2    480.0    0    74.651436
     14992009        9.9447511E-2    667.0    0    74.651436
     14992010        9.9447511E-2    181.0    0    74.651436
     18142004        9.9447511E-2    160.0    0    74.651436
     18142005        9.9447511E-2    80.0    0    74.651436
     18142006        9.9447511E-2    80.0    0    74.651436
     18142008        9.9447511E-2    240.0    0    74.651436
     18142009        9.9447511E-2    15.0    0    74.651436
     18142010        9.9447511E-2    37.0    0    74.651436
     34452003        9.9447511E-2    80.0    0    74.651436
     34452005        9.9447511E-2    320.0    0    74.651436
     34452006        9.9447511E-2    400.0    0    74.651436
     34452007        9.9447511E-2    880.0    0    74.651436
     34452008        9.9447511E-2    1280.0    0    74.651436
     34452009        9.9447511E-2    1149.0    0    74.651436
     34452010        9.9447511E-2    399.0    0    74.651436
     39922007        9.9447511E-2    80.0    0    74.651436
     39922010        9.9447511E-2    8.0    0    74.651436
     40222003        9.9447511E-2    160.0    0    74.651436
     40222006        9.9447511E-2    80.0    0    74.651436
     40222007        9.9447511E-2    80.0    0    74.651436
     40222008        9.9447511E-2    80.0    0    74.651436
     40222009        9.9447511E-2    56.0    0    74.651436
     40222010        9.9447511E-2    30.0    0    74.651436
     42222002        9.9447511E-2    1.0    0    74.651436
     42222003        9.9447511E-2    1.0    0    74.651436
     42222004        9.9447511E-2    2.0    0    74.651436
     42222005        9.9447511E-2    76.0    0    74.651436
     42222006        9.9447511E-2    85.0    0    74.651436
     42222007        9.9447511E-2    91.0    0    74.651436
     42222008        9.9447511E-2    152.0    0    74.651436
     42222009        9.9447511E-2    27.0    0    74.651436
     42222010        9.9447511E-2    37.0    0    74.651436
     43262003        9.9447511E-2    80.0    0    74.651436
     43262009        9.9447511E-2    2.0    0    74.651436
     43262010        9.9447511E-2    7.0    0    74.651436
     45742002        9.9447511E-2    80.0    0    74.651436
     45742003        9.9447511E-2    160.0    0    74.651436
     45742008        9.9447511E-2    80.0    0    74.651436
     45742009        9.9447511E-2    12.0    0    74.651436
     45742010        9.9447511E-2    7.0    0    74.651436
     50002003        9.9447511E-2    80.0    0    74.651436
     5064            9.9447511E-2    111.0    0    74.651436
     51892009        9.9447511E-2    2.0    0    74.651436
     51892010        9.9447511E-2    3.0    0    74.651436
     5488            9.9447511E-2    8.0    0    74.651436
     55532003        9.9447511E-2    80.0    0    74.651436
     55532004        9.9447511E-2    80.0    0    74.651436
     55532005        9.9447511E-2    80.0    0    74.651436
     55532006        9.9447511E-2    1.0    0    74.651436
     55532008        9.9447511E-2    81.0    0    74.651436
     55532009        9.9447511E-2    258.0    0    74.651436
     55532010        9.9447511E-2    59.0    0    74.651436
     58122004        9.9447511E-2    160.0    0    74.651436
     58122005        9.9447511E-2    80.0    0    74.651436
     58122006        9.9447511E-2    160.0    0    74.651436
     58122007        9.9447511E-2    400.0    0    74.651436
     58122008        9.9447511E-2    320.0    0    74.651436
     58122009        9.9447511E-2    65.0    0    74.651436
     58122010        9.9447511E-2    85.0    0    74.651436
     58482004        9.9447511E-2    160.0    0    74.651436
     58482005        9.9447511E-2    240.0    0    74.651436
     58482006        9.9447511E-2    880.0    0    74.651436
     58482007        9.9447511E-2    1120.0    0    74.651436
     58482008        9.9447511E-2    640.0    0    74.651436
     58482009        9.9447511E-2    826.0    0    74.651436
     58482010        9.9447511E-2    213.0    0    74.651436
     59862006        9.9447511E-2    160.0    0    74.651436
     59862007        9.9447511E-2    80.0    0    74.651436
     59862009        9.9447511E-2    141.0    0    74.651436
     59862010        9.9447511E-2    28.0    0    74.651436
     60412009        9.9447511E-2    3.0    0    74.651436
     60412010        9.9447511E-2    2.0    0    74.651436
     61562003        9.9447511E-2    400.0    0    74.651436
     61562004        9.9447511E-2    800.0    0    74.651436
     61562005        9.9447511E-2    880.0    0    74.651436
     61562006        9.9447511E-2    1040.0    0    74.651436
     61562007        9.9447511E-2    1280.0    0    74.651436
     61562008        9.9447511E-2    1760.0    0    74.651436
     61562009        9.9447511E-2    2839.0    0    74.651436
     61562010        9.9447511E-2    1135.0    0    74.651436
     61752005        9.9447511E-2    80.0    0    74.651436
     61752006        9.9447511E-2    80.0    0    74.651436
     61752007        9.9447511E-2    316.0    0    74.651436
     61752008        9.9447511E-2    241.0    0    74.651436
     61752009        9.9447511E-2    351.0    0    74.651436
     61752010        9.9447511E-2    51.0    0    74.651436
     62652009        9.9447511E-2    1.0    0    74.651436
     64352005        9.9447511E-2    80.0    0    74.651436
     64352007        9.9447511E-2    240.0    0    74.651436
     64352008        9.9447511E-2    480.0    0    74.651436
     64352009        9.9447511E-2    217.0    0    74.651436
     64352010        9.9447511E-2    115.0    0    74.651436
     69822007        9.9447511E-2    480.0    0    74.651436
     69822008        9.9447511E-2    320.0    0    74.651436
     72072009        9.9447511E-2    141.0    0    74.651436
     72072010        9.9447511E-2    105.0    0    74.651436


May 27 2010  5:20AM    5323319    72747    200    3.0050911E-3    19.0



4.6710202E-6    15.0    DOCNO
1.8785273E-7    19.0    DOCNO, ROW_ID


---                0.0    1.0    0    0.0
   46            100.46195    105.0    0    2405.4971
  618            228.46196    38.0    0    870.88971
  624            236.46196    13.0    0    3426.011
  787            468.46194    10.0    0    740.03107
 1830            327.46194    6.0    1    239.87608
 4507            482.46194    2.0    11    40.810951
 7846            462.46194    3.0    9    50.36813
11321            489.46194    2.0    9    53.700695
15404            440.46194    2.0    399    1.1038355
18115            449.46194    1.0    6    73.216873
43503            476.46194    7.0    474    1.0044053
43822            348.46194    8.0    2    172.5278
56306            246.46196    11.0    1    172.35326
61096            219.46196    13.0    1    205.89574
63473            202.46196    13.0    0    214.9482
64818            172.46196    15.0    0    185.49396
67825            215.46196    11.0    1    125.7245
71134            219.46196    11.0    1    201.45222
71709            226.46196    9.0    0    240.81259
74058            235.46196    8.0    2    105.36922
83149            277.46194    11.0    2    131.64447
88952            294.46194    17.0    1    185.90329
96101            144.46196    17.0    0    261.07486
98110            346.46194    12.0    1    341.83347
*к12115            503.46194    1.0    18    27.292036
*о4521            384.46194    1.0    382    1.0044053
*о7127            256.46194    1.0    255    1.0044053
*п251              384.46194    1.0    382    1.0044053
104                512.46198    1.0    510    1.0044053
109986            348.46194    16.0    11    29.794792
111157            187.46196    15.0    0    236.97917
114773            378.46194    1.0    5    63.709499
123                254.46196    23.0    6    40.829758
124                262.46194    25.0    1    202.81735
125                122.46195    34.0    5    21.214859
127                321.46194    14.0    8    37.039299
128089            265.46194    12.0    3    70.073502
129513            478.46194    1.0    2    159.81866
148507            465.46194    10.0    10    44.375668
149966            241.46196    6.0    1    146.0954
154939            363.46194    8.0    5    61.25618
15614              128.46196    2.0    3    39.842125
163112            474.46194    6.0    5    94.275154
166793            210.46196    13.0    5    38.936501
16818              249.46196    2.0    2    93.416954
177485            376.46194    7.0    21    17.715305
180425            298.46194    7.0    4    73.904991
188916            287.46194    7.0    5    54.978226
1957              256.46194    2.0    7    32.386051
20336              384.46194    1.0    57    6.7073765
204957            220.46196    8.0    10    21.381958
21                339.46194    43.0    4    71.491638
218340            295.46194    3.0    4    67.367867
222306            321.46194    1.0    6    52.022861
233463            512.46198    1.0    32    15.943987
234018            256.46194    1.0    9    27.102596
23903/2/1/1        384.46194    1.0    16    22.908178
24333              256.46194    2.0    26    9.6024599
252551            384.46194    2.0    21    18.250793
25454*/1          256.46194    1.0    8    29.372711
2876/1            512.46198    1.0    160    3.1920488
29691              384.46194    1.0    348    1.1042041
31406              384.46194    1.0    348    1.1042041
319840            256.46194    1.0    255    1.0044053
3270              384.46194    1.0    348    1.1042041
344173            385.46194    2.0    14    27.504692
358985            384.46194    1.0    48    7.9340987
37827              423.46194    2.0    65    6.4375529
389596            357.46194    2.0    27    13.060928
3931              313.46194    2.0    110    2.8432131
4                  275.46194    124.0    8    32.611973
4266              512.46198    1.0    510    1.0044053
521                144.46196    2.0    143    1.0044053
531                382.46194    5.0    8    44.336876
5538              257.46194    2.0    4    58.66206
60                384.46194    2.0    11    34.157837
6171/1            256.46194    1.0    5    42.855774
629                293.46194    2.0    63    4.613544
75                410.46194    30.0    47    8.5653276
98                509.46194    11.0    10    48.66016
R002645            274.46194    2.0    16    16.812269
б1                288.46194    2.0    187    1.540327
б109              233.46196    2.0    60    3.8664989
б16                286.46194    2.0    68    4.2016225
б1826              384.46194    3.0    6    59.780216
б28                290.46194    2.0    7    38.402973
б80                383.46194    2.0    198    1.9327819
б963              282.46194    3.0    9    28.956753
бр194              496.46194    2.0    30    16.280867
бр5963            401.46194    2.0    53    7.5445948
бр6510            256.46194    2.0    23    10.821054
В-1                461.46194    2.0    418    1.1037204
в390_ф40          256.46194    1.0    39    6.5144658
в506              395.46194    2.0    131    3.0082054
в590              256.46194    1.0    54    4.6889334
Вг144              512.46198    1.0    467    1.0968032
Вг1621            256.46194    1.0    12    20.084141
Вг4835            512.46198    1.0    510    1.0044053
ВгС44              512.46198    1.0    135    3.7925019
вл4096            511.46194    2.0    19    26.075144
Дог                501.46194    65.0    29    17.003719
ЗАО-07-л2368      256.46194    1.0    5    50.812893
ЗАО-10-Пт153      512.46198    1.0    510    1.0044053
И143/09-Д          400.46194    13.0    180    2.2228465
к121              256.46194    2.0    15    16.104504
к217              512.46198    1.0    10    48.169682
к6310              512.46198    1.0    464    1.1034805
к9279              512.46198    1.0    196    2.6053488
к9496              256.46194    1.0    9    26.472019
кр207              512.46198    2.0    176    2.8981133
кр2257            256.46194    1.0    33    7.7009296
кр5488            512.46198    1.0    467    1.0968032
кр6785            512.46198    1.0    116    4.38872
кр8624/1          512.46198    1.0    109    4.6886358
л14                511.46194    2.0    354    1.4414421
л20_ф166          256.46194    1.0    21    12.136874
л5846/1            512.46198    1.0    53    9.601202
л93_ф166          512.46198    1.0    52    9.8473396
ли12009/1/1/1      256.46194    1.0    18    14.075667
ли1803            512.46198    1.0    37    13.733577
ли552              384.46194    1.0    382    1.0044053
ли7977            384.46194    1.0    382    1.0044053
Мрк89              384.46194    1.0    382    1.0044053
мт271              384.46194    1.0    382    1.0044053
н12354            384.46194    1.0    382    1.0044053
н864/1            259.46194    2.0    258    1.0044053
Нчк2408            384.46194    1.0    249    1.5403128
о1_ф370            368.46194    2.0    366    1.0044053
о109_ф166          258.46194    2.0    33    7.6977115
о121              259.46194    2.0    17    15.194752
о165              323.46194    2.0    16    19.894131
о1766              256.46194    2.0    3    65.922768
о251              280.46194    2.0    87    3.1919804
о372              255.46196    2.0    18    13.480292
о7886              384.46194    1.0    31    12.135526
ос291              348.46194    2.0    317    1.0988439
п14623/1          384.46194    1.0    382    1.0044053
п2086              258.46194    2.0    10    25.476034
п2655              384.46194    1.0    6    57.473549
п313              298.46194    3.0    10    29.152456
п373_ф278          384.46194    1.0    13    29.147175
п9061              384.46194    1.0    40    9.6016207
п9755/1            384.46194    1.0    348    1.1042041
Пт282              384.46194    1.0    44    8.7258511
р10309            384.46194    1.0    350    1.0982455
р11616/1          384.46194    1.0    249    1.5403128
р1328              384.46194    1.0    81    4.688735
р1432              384.46194    1.0    29    12.973774
р166_ф370          384.46194    1.0    75    5.0662103
р2539/1            384.46194    1.0    54    7.0955534
р3612              384.46194    2.0    26    14.249214
р4202              384.46194    1.0    31    12.135526
р591              384.46194    1.0    75    5.0662103
р97                384.46194    2.0    70    5.4823108
РС-04-678          384.46194    1.0    34    11.230679
РЭ57              384.46194    1.0    50    7.5414853
с1271_ф40          384.46194    1.0    16    23.708727
С13921/1          384.46194    1.0    36    10.411587
С251_ф166          512.46198    1.0    510    1.0044053
С6409              384.46194    1.0    350    1.0982455
с6687              384.46194    1.0    16    23.307232
С8440              384.46194    1.0    33    11.643694
сп1036            384.46194    1.0    54    7.0955534
сп1272/1/1        384.46194    1.0    12    31.078287
сп1904/1/1/1      384.46194    1.0    249    1.5403128
сп2333            384.46194    1.0    57    6.7073765
сп3374            384.46194    1.0    30    12.553459
сп4283            384.46194    1.0    36    10.411587
сп4925/1          384.46194    1.0    48    7.9340987
сп5710            384.46194    1.0    26    14.249214
сп7878            384.46194    1.0    81    4.688735
сп96              436.46194    2.0    397    1.0975566
ст5076/1          408.46194    2.0    406    1.0044053
Сэ826              512.46198    1.0    510    1.0044053
т2590              384.46194    1.0    65    5.9006729
т381              384.46194    1.0    42    9.1250257
т5537              384.46194    1.0    70    5.4823108
тв36              392.46194    2.0    85    4.57656
тв469/1/1          384.46194    1.0    18    21.011658
тС53              459.46194    2.0    66    6.9392896
у12267            384.46194    1.0    27    13.82163
у14343            439.46194    2.0    437    1.0044053
у17270            512.46198    1.0    510    1.0044053
у2359/1            416.46194    2.0    414    1.0044053
у3203              512.46198    1.0    52    9.8473396
у4982/2            400.46194    2.0    398    1.0044053
у7736              512.46198    1.0    510    1.0044053
ул234              412.46194    2.0    373    1.1040071
ульян114          384.46194    1.0    7    50.879314
ф5-906250460      512.46198    1.0    443    1.15441
чр2406            512.46198    1.0    443    1.15441
э17                401.46194    2.0    98    4.0904431
э2238              384.46194    2.0    18    21.011658
э286              383.46194    2.0    25    15.194069
э373              384.46194    3.0    8    45.483765
э52                470.46194    3.0    8    57.385818
Ю-54              415.46194    4.0    19    21.008913
январь98          118.46195    1.0    1    65.993271
январь99          1.4619542    1.0    1    1.0044053

(127) (128)
Следил за Вашей дискуссией и пробовал у себя.
И ничего не понимал.
Пока внимательно не посмотрел на physical reads для разных вариантов.
После этого перестроил идексы: DBCC DBREINDEX(_1sjourn).
И проверил еще раз.
Проверьте и Вы. Будете приятно удивлены.

(129) во первых не могу.
некоторые работают до 22,23
во вторых каждую ночь идет дефрагментация defrag всей базы и обновление статистики по всем индексам
в третьих даже если индексы и "плохие" то они "плохие" для всех тестов
практически одинаково. Общая тенденция останеться той же.

(130)
1. По планам выполнения. Конечно я смотрел Execution, а не Estimated.
2. Для Index Seek physical reads у меня был неожиданно большой. Это говорит о неоптимальности индекса.
3. Дефрагментация и перестройка индексов - две большие разницы.
4. Почему бы Вам не попробовать на копии базы.
5. Для себя я уже сделал вывод и включу перестройку индексов в шедулер.

(130)у тебя тесты нечестные.

+132 я только сейчас увидел, что тесты с разными критериями.

(132) тест №7  это твой тест.
Давай свои тесты.

Просто я считаю ( может и ошибчно ) что надо делать поиск
по номеру как в тесте № 4 ( 1с.exe так и делает  только на каждый год свой запрос)
ну и у меня мой поиск работает как в тесте 4


Здесь же утверждалось что тест № 2  лучше. Я с этим не согласен.
см (82)
>>>   and j.dnprefix > '     15124'
>>>   наиболее эффективно.

(131) Вы буфер данных чистили после переиндексации ?
а то ведь все в кеше
см например пост (114)

(135) Да.

(136) Ну тогда надо придумать сначала какой то тест который покажет
Время до выполнения перестроения индексов
Сделать дефрагментацию
Прогнать тест
Сделать переиндексацию
Прогнать тест


Ставить переиндексацию ночью рискованно ( если только в субботу раз в неделю). Вдруг индекс "слетит" и придеться восстанавливать утром в рабочее время.
По закону подлости это произойдет в самый плохой для Вас момент.

(117) А можете выложить план запроса в текстовом виде? И результат
SELECT COUNT(DISTINCT dnprefix), COUNT(*)
FROM _1sjourn
?
Если количество разных dnprefix мало, то план будет показывать Index Seek, но внутри все равно будет сканирование. Чтобы увидеть его в графическом представлении - посмотрите во всплывающей подсказке на Index Seek - какие поля стоят в Seek Predicates и Predicates.

(138) результат запроса
SELECT COUNT(DISTINCT dnprefix), COUNT(*) FROM _1sjourn
310    5328736

"А можете выложить план запроса в текстовом виде?"  
о каком тесте идет речь ?

Перечитал ветку
написал новый тест
тест на основе  МихаилМ пост (67)

тест № 8

SELECT
   Жур.IDDoc,Жур.dnprefix
FROM
_1SJourn as Жур
WHERE
 Жур.DocNo = '18311' and Жур.IDDocDef  = 196
and   (Жур.dnprefix  between  '       196        ' and '       196z       ' )




Результаты теста №8    19    23   24

(139) о любом, где в плане видно Index Seek. Но, судя по соотношению количества записей, SQL Server только думает, что использует Index Seek, а фактически все сводится к Index Scan'у.. Т.е. он смотрит, что поля dnprefix и docno в индексе стоят рядом, на оба есть условия => лучше всего было бы использовать Index Seek, а уже потом, когда во время выполнения накладывает условия, ему приходится "просматривать" все записи индекса, поскольку условие на dnprefix, на самом деле, условием отбора не является

(141) присоединяюсь к утверждению

(141) Как получить план запроса в текстовом виде ?

Также есть предложение продублировать ветку на 1cpp.ru - просто
там можно поместитьв пост  и картинку и файл прикрепить

(143) http://www.sql.ru/faq/faq_topic.aspx?fid=393

SET SHOWPLAN_TEXT ON
go
SELECT
   Жур.IDDoc,Жур.dnprefix
FROM
_1SJourn as Жур
WHERE
Жур.dnprefix<>'' and Жур.DocNo = '18311' and Жур.IDDocDef  = 196
go
SET SHOWPLAN_TEXT OFF
go

Результат

 |--Filter(WHERE:([Жур].[IDDOCDEF]=Convert([@3])))
      |--Bookmark Lookup(BOOKMARK:([Bmk1000]), OBJECT:([Millenium].[dbo].[_1SJOURN] AS [Жур]) WITH PREFETCH)
           |--Parallelism(Gather Streams)
                |--Index Seek(OBJECT:([Millenium].[dbo].[_1SJOURN].[DOCNO] AS [Жур]), SEEK:([Жур].[DNPREFIX] < '' OR [Жур].[DNPREFIX] > ''),  WHERE:([Жур].[DOCNO]='18311') ORDERED FORWARD)

SET STATISTICS PROFILE ON
go
SELECT
   Жур.IDDoc,Жур.dnprefix
FROM
_1SJourn as Жур
WHERE
Жур.dnprefix<>'' and Жур.DocNo = '18311' and Жур.IDDocDef  = 196
go
SET STATISTICS PROFILE OFF
go


результат

4    1    SELECT [IDDoc]=[Жур].[IDDoc],[dnprefix]=[Жур].[dnprefix] FROM [_1SJourn] [Жур] WHERE [Жур].[dnprefix]<>@1 AND [Жур].[DocNo]=@2 AND [Жур].[IDDocDef]=@3    3    1    0    NULL    NULL    NULL    NULL    40.168922    NULL    NULL    NULL    7.557622    NULL    NULL    SELECT    0    NULL
4    1      |--Filter(WHERE:([Жур].[IDDOCDEF]=Convert([@3])))    3    3    1    Filter    Filter    WHERE:([Жур].[IDDOCDEF]=Convert([@3]))    NULL    40.168922    0.0    6.5621367E-5    115    7.5576177    [Жур].[DNPREFIX], [Жур].[IDDOC]    NULL    PLAN_ROW    0    1.0
7    1           |--Bookmark Lookup(BOOKMARK:([Bmk1000]), OBJECT:([Millenium].[dbo].[_1SJOURN] AS [Жур]) WITH PREFETCH)    3    4    3    Bookmark Lookup    Bookmark Lookup    BOOKMARK:([Bmk1000]), OBJECT:([Millenium].[dbo].[_1SJOURN] AS [Жур]) WITH PREFETCH    [Жур].[IDDOCDEF], [Жур].[DNPREFIX], [Жур].[IDDOC]    136.71118    0.42499661    1.503823E-4    115    7.5575523    [Жур].[IDDOCDEF], [Жур].[DNPREFIX], [Жур].[IDDOC]    NULL    PLAN_ROW    0    1.0
7    1                |--Parallelism(Gather Streams)    3    6    4    Parallelism    Gather Streams    NULL    NULL    136.71118    0.0    2.8888192E-2    62    7.1324053    [Bmk1000]    NULL    PLAN_ROW    -1    1.0
7    8                     |--Index Seek(OBJECT:([Millenium].[dbo].[_1SJOURN].[DOCNO] AS [Жур]), SEEK:([Жур].[DNPREFIX] < '' OR [Жур].[DNPREFIX] > ''),  WHERE:([Жур].[DOCNO]='18311') ORDERED FORWARD)    3    7    6    Index Seek    Index Seek    OBJECT:([Millenium].[dbo].[_1SJOURN].[DOCNO] AS [Жур]), SEEK:([Жур].[DNPREFIX] < '' OR [Жур].[DNPREFIX] > ''),  WHERE:([Жур].[DOCNO]='18311') ORDERED FORWARD    [Bmk1000], [Жур].[DOCNO]    136.71118    4.9883933    1.4753946    62    6.463788    [Bmk1000], [Жур].[DOCNO]    NULL    PLAN_ROW    -1    1.0

так как насчет продублировать ветку на 1сpp ?
с одной стороны можем запутаться. и может так неправильно делать.
с другой стороны форум чуть удобней. да и кто-то есть там
и по каким либо соображениям его нет тут.

(145) Да, так и есть..

SEEK:([Жур].[DNPREFIX] < '' OR [Жур].[DNPREFIX] > ''),  WHERE:([Жур].[DOCNO]='18311')

По первому столбцу индекса он находит записи, удовлетворяющие условию (т.е. всю таблицу), а потом из них отбирает те, которые удовлетворяют условию docno = '18311'.
Все-таки непонятно чем вызвана разница во времени выполнения в три раза в (82). Хотя если в таблице есть записи с dnprefix <= '     15124', то все становится объяснимо.
(147) по поводу 1cpp ничего не могу вам сказать, но если хотите переместиться туда, я, в принципе, не против (:

завел аналогичную ветку
http://www.1cpp.ru/forum/YaBB.pl?num=1275037619

Также проверил на sql2005 sp2 ( база таже на вчера УРБД )
SELECT
   Жур.IDDoc,Жур.dnprefix
FROM

_1SJourn as Жур
WHERE
Жур.dnprefix<>'' and Жур.DocNo = '18311' and Жур.IDDocDef  = 196


графический алан выполнения тоже Index Seek