Подскажите пожалуйста, как лучше оптимизировать запрос:

ВЫБРАТЬ
    РеализацияТоваровУслугТовары.Номенклатура КАК Номенклатура,
    СУММА(РеализацияТоваровУслугТовары.Количество) КАК Количество
ИЗ
    Документ.РеализацияТоваровУслуг.Товары КАК РеализацияТоваровУслугТовары
ГДЕ
    РеализацияТоваровУслугТовары.Ссылка.Проведен = ИСТИНА
    И РеализацияТоваровУслугТовары.Ссылка.Дата МЕЖДУ &ДатаНач И &ДатаКон
    И РеализацияТоваровУслугТовары.Ссылка.ПервыйРаз = ИСТИНА

СГРУППИРОВАТЬ ПО
    РеализацияТоваровУслугТовары.Номенклатура

Отчет выдает нужную информацию, но работает очень медленно

Сделать вместо неявного левого внутреннее соединение. _возможно_ добавить индекс по полю ПервыйРаз

сделать оборотный регистр "Первые продажи" и заполнять его при проведении, брать информацию из него.

Нужно план запроса смотреть.
Но явно, по проведён и первыйраз - нет индексов.

объединить таблицу ТЧ с таблицей документа, левым соединением как (2) посоветовал

(0)правильнее использовать данные из регистра

а так
во времянку отбираем кто в первый раз

в основном запросе
внутренним соединением пристёгиваем таблицу товаров

(6) вероятность того, что вариант с временной таблицей медленнее (2) где-то 90%

Если документов с признаком "ПервыйРаз" много меньше документов, входящих в диапазон - индексировать его, иначе - отдельный регистр. Остальное - глупости.

Всем большое спасибо за отзывчивость!

(8) Попробовал разные варианты, решил что буду использовать отдельный регистр, спасибо!

(9) У тебя вообще крайне странный реквизит "Первый раз", по-моему. Интересно, что он означает. Первый документ для контрагента?

Его можно найти и без такого реквизита. По-моему, ты к реализации изначально не особо подошел. Возможно, как сказали нужен регистр, а может, ничего и не нужно

(10) реквизит первый раз означает, что ранее на основании этого документа не создавался другой документ, а именно ветеринарная справка

(2) Во первых там будет внутреннее
Во вторых индекс как мёртвому припарки.

PS: Не устаю повторять учите матчасть.

(0) Запросы нужно правильно писать и всё будет хорошо

ВЫБРАТЬ
    тзТовары.Номенклатура,
    СУММА( тзТовары.Количество ) КАК Количество
ИЗ
    Документ.РеализацияТоваровУслуг КАК докРН

    ЛЕВОЕ СОЕДИНЕНИЕ Документ.РеализацияТоваровУслуг.Товары КАК тзТовары
    ПО тзТовары.Ссылка = докРН.Ссылка
ГДЕ
    докРН.Дата МЕЖДУ &ДатаНач И &ДатаКон
    И докРН.Проведен
    И докРН.ПервыйРаз

СГРУППИРОВАТЬ ПО
    тзТовары.Номенклатура

Дак в регистр оборотный "продажи" этот док пишет, из него и бери. Поле расход за период.
-Зачем ужика (документ) тиранишь? (с)

(12) Внутреннее соединение лучше.  Иначе NULL получите в сумме.

(0) "Первый раз" улыбает конечно... Начиная от названия... заканчивая тем что статусные поля нужно выносить в регистры сведений.

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

А кто-то еще и самоутвердиться может за счет менее продвинутых

(13) именно так и сделал в итоге )) Спасибо большое

(11) лучше ветсправку иши

(14) Тебя учить только портить... где ты там null увидел?

Да блин )))
ПервыйРаз это не мое название, это было еще до меня )))
там еще есть один реквизит "СтранныйНаборЧисел" )))))

(20) Угадай, что будет в
тзТовары.Номенклатура,
    СУММА( тзТовары.Количество ) КАК Количество

если у документа шапка будет заполнена, а ТЧ Товары - нет?

(22) Ну тогда внутренне, а вообще если такое возможно в учётной системе то это хреновая учётная система

(23) УПП плохая учетная система?

(24) Если система позволяет вводить данные о продаже в виде шапки то да, недоработка и не важно что это хоть УПП хоть нет.

(25) Все-таки хотелось бы услышать прямой ответ. Человек который хотя-бы приблизительно знает чем 7.7 отличается от 8.х уже должен был бы понять свою ошибку.

(26) Я не имел ввиду функционал. Есть правило о корректном вводе данных, нужно контролировать данные чтобы они были изначально корректные.

(27) Предлагаю открыть в УПП документ реализация товаров и услуг. Сначала в предприятии. Потом в конфигураторе.

Потом примерить (12) к этому документу еще раз.

(29) К чему ведёшь то? Что можно создать документы без табличной части и по этому не корректный запрос из-за этого?

(29) Ну и что, ты примерил запрос? И каков результат? Загадочный вы наш...

(31) Ты точно программист?

(12) "Во вторых индекс как мёртвому припарки." Действительно, придумали ерунду какую-то: индексы, запросы.

(32) Viso76 не отрицал, что ТЧ можно не заполнять и провести док и какой после получится результат запроса, а ты ему такое :))
(25) Тут ты конечно перегибаешь и отчасти не прав. Создаётся много разных документов, у которых может быть и не одна Табличная часть, так вот одна может быть заполнена, а другая нет и наоборот. Так что документ может быть с пустой ТЧ и в запросе, либо внутреннее соединение, либо проверка на Есть NULL (ЕстьNULL),в зависимости что необходимо получить.

(27) Так вот, В данном случае надо получать всегда корректные данные, а не проверять,что их ввели в ТЧ.

(34) Ну вот, всю интригу испортил :)

<реквизит первый раз означает, что ранее на основании этого документа не создавался другой документ, а именно ветеринарная справка>
а не проще ли проверять это по заполненности/незаполненности документа основания?

(36) Да какая в заднице интрига? Может у тебя то что написано в (34) интрига, а для меня нет. Я исхожу из текущего запроса топикастра, а не всякие там абстракции. Если услуга заносится в отдельную табличную часть, то нужно внутреннее ставить. Всякие "Есть NULL" или "СУММА( ЕстьNull(...) )" только замедляют запрос и да (33) индексы в конкретных случаях могут замедлять неожиданно, и совет в  (2) по поводу индекса для запроса в (0) скорее всего ухудшит производительность. (32) Думаю что да, а ты мой гениальный?

(38) Ты че такой дерзкий.

?

(37) там такая структура, что просто по сути нет документа основания. В двух словах скорее всего не смогу объяснить. Это конфу нужно смотреть + комментарии пользователей

(39) Да по тому что ты из-за копеешных знаний раздулся как слон :) И ещё в данном случае из-за поля ПервыйРаз запрос по документу скорее всего будет работать быстрее чем запрос к регистру с последующим соединением с тем же документом.

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

(43) Сказать нечего по сути? Опровергни мои слова если сможешь.

Перечитай еще раз тему начиная с (22). Дальнейшие консультации по вопросу почему запрос в (12) не верен - платные.

(27) Заведены услуги, товары пусто

(45) Тебе глаза разуть в (30), (38). Консультации мне? Да это я тебе скорее всего платные могу дать консультации. Если проблема из-за левого соединения, то я тебе сказал всё зависит от конфигурации, может и табличная часть всегда быть заполнена. (45) И да хватить уже пукать в лужу.

(47) Да ладно, чувак, не рви пукан. Признай уже что не прав и забудь.

Элементарный запрос, а столько понаписано.
В 13 и 14 решения данного простого вопроса.

(48) С чего это ещё? Я не согласен что всегда нужно внутреннее ставить. (46) Услуги могут содержаться в той же табличной части, а у номенклатуры может быть признак что это услуга. (49) Решение данного вопроса в (12) считаю наилучшим, поставить внутреннее если услуги отдельная ТЧ. Остальная стена текста из-за mehfk который начал показывать свои сантиметры, только чувак не с той стороны стола мерит.

(50) Жги еще.

(50) Большинство типовых конфигураций услуги отдельной ТЧ

(38) Давай уже конкретный случай в котором индекс реквизита, по которому накладывается условие выборки, замедляет выборку.

(50)Потому что (14). Остальное все словоблудие.

(53) (38) там ответ

(54) Я не спорю если услуги отдельно в конфе, то внутренее, если нет то левое, так как лишняя проверка во внутреннем, при условии одной ТЧ и ЧТ всегда заполнена ухудшает производительность.

(55) ЕстьNULL работает очень и очень быстро, не стоит на этом вообще заострять внимание.

(55) этот "индексы в конкретных случаях могут замедлять неожиданно"?

Так в каких конкретных случаях индексы могут неожиданно замедлить выборку?

(56) 0-O ты где узнал, что внутренее соединение ухуджает производительность? Просто логически поразмыслил?

(57) Лишняя проверка - нагрузка на ПЦ, она избыточна. Нужно смотреть план исполнения но скорее всего в начале данные отберутся, а затем уже будут делаться агрегаты но я в этом не уверен на 100%, а по этому лучше внутреннее, чтобы память меньше расходовать.

(59) Ну там тупо есть проверка дополнительная при соединении, возможно что это микросекунды, но всё же...

(61) Я говорю это по конкретный случай, про то что ТЧ есть всегда, а то начнёте тут развозить...

(60) Да вот не лишняя она. Вот ты упертый товарищ.

(63) В левом соединении не лишняя, но я уже отписался нет ТЧ ставить левое. Это вы упёртые читать нужно что пишут.

(64) но я уже отписался нет ТЧ ставить внутреннее ( описался )

(65) Ты сдавал спеца по платформе или требования хоть раз смотрел?

(66) спеца не смотрел, требования чего?

Напоминаешь только только окрылившегося Программиста 1С, при этом только в своей голове.

(68) По моему совету (12), кроме внутреннего ещё есть претензии? Или все тут об астракциях думают, а не конкретный случай рассматривают? Если претензий нет, то кругом, раз, два

(67) МатЧасти (как говоришь) нахватался вроде, а как использовать не знаешь.

(70) Ну давай, жги, только не в лужу, а обоснованно, с примерами. Запрос (12) я накатал лёжа на диване в блокноте почти копипастом, про внутренне в тот момент не думал, так как в текущий момент в самописке ТЧ всегда заполнена. Ты давай умудренный знаниями покажи моменты где я не прав. Внутреннее мы уже обсудили, что ещё? Меня интересует утверждение "а как использовать не знаешь"

(61) план запроса смотрел?

(71) Всё просто, чем твой запрос отличается таким особенным от (0) ?

(73) С тобой всё понятно. Ну тогда напиши в какой запрос будет переведён (0) для SQL и тогда всё поймёшь.

(74) По твоему отличный прирост в производительности мы увидим? Тебе когда необходимо получить реквизит какого-либо ещё реквизита, тоже запрос пишешь?

(75) Смотря что, могу и через точку, если гарантированно SQL точкой не будет испорчен

ЛЕВОЕ

'SELECT
T2._Fld28317RRef,
CAST(SUM(T2._Fld28322) AS NUMERIC(26, 8))
FROM dbo._Document862 T1
LEFT OUTER JOIN dbo._Document862_VT28315 T2
ON (T1._IDRRef = T2._Document862_IDRRef) AND T2._Fld1704 = T1._Fld1704
WHERE ((T1._Fld1704 = P1)) AND (T1._Posted = 0x01 AND ((T1._Date_Time >= @P2) AND (T1._Date_Time <= @P3)))
GROUP BY T2._Fld28317RRef',N'P1 numeric(10),@P2 datetime2(3),@P3 datetime2(3)',0,'4015-04-01 00:00:00','4015-04-30 23:59:59'

ВНУТРЕННЕЕ
'SELECT
T2._Fld28317RRef,
CAST(SUM(T2._Fld28322) AS NUMERIC(26, 8))
FROM dbo._Document862 T1
INNER JOIN dbo._Document862_VT28315 T2
ON (T1._IDRRef = T2._Document862_IDRRef) AND T2._Fld1704 = T1._Fld1704
WHERE ((T1._Fld1704 = P1)) AND (T1._Posted = 0x01 AND ((T1._Date_Time >= @P2) AND (T1._Date_Time <= @P3)))
GROUP BY T2._Fld28317RRef',N'P1 numeric(10),@P2 datetime2(3),@P3 datetime2(3)',0,'4015-04-01 00:00:00','4015-04-30 23:59:59'

(0)
'SELECT
T1._Fld28317RRef,
CAST(SUM(T1._Fld28322) AS NUMERIC(26, 8))
FROM dbo._Document862_VT28315 T1
LEFT OUTER JOIN dbo._Document862 T2
ON (T1._Document862_IDRRef = T2._IDRRef) AND (T2._Fld1704 = P1)
WHERE ((T1._Fld1704 = @P2)) AND (T2._Posted = 0x01 AND ((T2._Date_Time >= @P3) AND (T2._Date_Time <= @P4)))
GROUP BY T1._Fld28317RRef',N'P1 numeric(10),@P2 numeric(10),@P3 datetime2(3),@P4 datetime2(3)',0,0,'4015-04-01 00:00:00','4015-04-30 23:59:59'

(80) Благодарствую! Некогда было подобное выкатить.

(80) Всё правильно. (73) Почувствуй разницу. Теперь объясни что будет делать база данных на запросе (79) и (80)

Никого не смущает, что в (0) суммируется количество в разных ед.измерения?

(82) Тесты, тесты со временем давай. Не очевидно, что SQL плохо в любом случае отработает.

(82) Я тебе точно говорю что то, что будет делать SQL, зависит от того, как ее оптимизатор обработает эти запросы. В 99% случаев они будут обрабатываться идентично.

(84) Тесты к (80) с благодарностью

(85) Соглашусь, что если оптимизатор отработает хорошо, то да, а если это файловая база? Я предпочитаю не полагаться на оптимизатор.

(86) при левом соединении будет null что ошибка, в (0) не оптимально

план запроса в (0)
StmtText                                                                                                                                                                                                                                                                                                                                                                                                                  
--------                                                                                                                                                                                                                                                                                                                                                                                                                  
Compute Scalar(DEFINE:([Expr1005]=CONVERT(numeric(26,8),[Expr1004],0)))                                                                                                                                                                                                                                                                                                                                                    
  |--Parallelism(Gather Streams)                                                                                                                                                                                                                                                                                                                                                                                          
       |--Stream Aggregate(GROUP BY:([T1].[_Fld28317RRef]) DEFINE:([Expr1004]=SUM([partialagg1006])))                                                                                                                                                                                                                                                                                                                      
            |--Sort(ORDER BY:([T1].[_Fld28317RRef] ASC))                                                                                                                                                                                                                                                                                                                                                                  
                 |--Parallelism(Repartition Streams, Hash Partitioning, PARTITION COLUMNS:([T1].[_Fld28317RRef]))                                                                                                                                                                                                                                                                                                          
                      |--Hash Match(Partial Aggregate, HASH:([T1].[_Fld28317RRef]), RESIDUAL:([pepsico_erp].[dbo].[_Document862_VT28315].[_Fld28317RRef] as [T1].[_Fld28317RRef] = [pepsico_erp].[dbo].[_Document862_VT28315].[_Fld28317RRef] as [T1].[_Fld28317RRef]) DEFINE:([partialagg1006]=SUM([pepsico_erp].[dbo].[_Document862_VT28315].[_Fld28322] as [T1].[_Fld28322])))                                          
                           |--Nested Loops(Inner Join, OUTER REFERENCES:([T2].[_IDRRef], [Expr1007]) WITH UNORDERED PREFETCH)                                                                                                                                                                                                                                                                                              
                                |--Clustered Index Seek(OBJECT:([pepsico_erp].[dbo].[_Document862].[_Document862HPK] AS [T2]), SEEK:([T2].[_Fld1704]=[@P1]),  WHERE:([pepsico_erp].[dbo].[_Document862].[_Date_Time] as [T2].[_Date_Time]>=[@P3] AND [pepsico_erp].[dbo].[_Document862].[_Date_Time] as [T2].[_Date_Time]<=[@P4] AND [pepsico_erp].[dbo].[_Document862].[_Posted] as [T2].[_Posted]=0x01) ORDERED FORWARD)
                                |--Clustered Index Seek(OBJECT:([pepsico_erp].[dbo].[_Document862_VT28315].[_Documen862_VT28315_IntKeyInd] AS [T1]), SEEK:([T1].[_Fld1704]=[@P2] AND [T1].[_Document862_IDRRef]=[pepsico_erp].[dbo].[_Document862].[_IDRRef] as [T2].[_IDRRef]) ORDERED FORWARD)

+(89) фиговенько вставляется )

а в чем смысл СУММА(РеализацияТоваровУслугТовары.Количество)
зачем суммировать количество различной номенклатуры?

(91) Почему разной? Группировку по номенклатуре ещё никто не отменял

(89) Спасибо, можешь привести план запроса (79). Мне интересно ГДЕ ( все пункты ) накладывается до соединения сокрее всего. И в начале будет отбор по индексу Дата ( диапазон ), а далее наложены другие фильтра, и только в последнем моменте внутренее...

вы чё спорите?
в (8) правильный ответ

(94) Нафига делать отдельный индекс, которые будет ухудшать INSERT, если можно и так построить достаточно быстро работающий запрос? Почитай по OLTP где DBA прежде чем добавить индекс собирают информацию о там как это отразится на других частях системы, а тут давайте по каждому чиху индексов насоздадим... некошерно это.

(0) Усилить сервер ещё не предлагали? А то выборка по одной таблице медленно работает...

(0) Вариант 2. Подготавливать данные в отдельный регистр. Обновлять механизмом регистрации изменений.

(97) Уже даже не смешно. Из-за неправильно написанного запроса пытаются годзилу тут сваять...

(98) проясните, пожалуйста, несведущему в планах, что в (89) не так напланировано, по вашему. Спасибо!

(99) план одинаков практически у всех запросов

+ (100) я не сказал что он не правильный

(100) Кагбэ, это ожидаемо. Все приведённые запросы - одни и те же... из штанов.

(102) спор идет за левое соединение )

(100) используеться seek where, означает что отсутствует индекс, идет частичное сканирование таблицы . Далее идет нестед лупс, возможно он не должен там быть. Напишите пожалуйста количество ожидаемых и выводимых строк

(99) Я писал в (87) (103) За левое не идёт спора, я уже написал, если есть услуги в отдельной таблице то внутреннее.

(95) Ты умными словами не раскидывайся, везде нужно голову включать: нужно сравнить сколько раз добавляется документ, и сколько раз по нему отчет будет формироваться, после этого принимать решение по индексу.

PS Регистр по сути даст тот же тот же индекс только в отдельной таблице, и внезапно, падения производительности на этом практически не будет.

(106) Зачем раздувать базу? Зачем лишнее писать в доп таблицу? Внезапно много зачем

(104) на какой момент?

(92) тупанул чето

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

(110) к (108)

Идите все в регистры))) - они оптимизированы для запросов через 1С.

(107) Я, таки, одобряю ваш подход к ресурсам сервера. Гои могут подождать свои отчеты пару дней, а сервера нынче очень дороги.

(104) табл док, 12000, тч 11
вложенные циклы 144к
сортировка 0,009%

(112) Ты имеешь ввиду особенные таблицы в РСУБД? ( не только лишь все мало кто может это сделать :)

ого.Смотри у тебя на нестед лупсе просто пидец!

(114) А что за циферки будут для (79)?

не увлекайтесь, дайте поработать

(113) Очередной раздуватель из мухи слона?

(116) для него оптимально 5-6 выполнений. Оптимизатор пипец как просчитался. у тебя получается идет 11 раз частичное сканирование 12к строк таблицы(если не ошибаюсь). а сколько строк всего возвращается в итоге?

(113) Сначала проверь насколько увеличится база и насколько замедлится insert после добавления одного индекса по реквизиту с типом булево (допустим в таблицу с 100000 документов), потом расскажешь про мух и слонов.

(121) а зачем по булево индексировать, там же селективность никакая?

(122) Я думаю что этот индекс тупо будет проигнорирован в плане и увеличит время INSERT-а, будет занимать место на диске и да "гои" (113) так и не дождутся своего отчёта

(122) (123) А вы попробуйте из базы в 100000 записей выбрать 500 у которых это булево установлено. Вы тут теории двигаете, а я на практике проверял.

(124) Мы обсуждаем данный запрос или абстракцию? Перечитай (38) по поводу абстракций. Так и хочется сказать словами Лаврова.

(120) 250 строк на финише

+ (126) база ерп большая и старенькая, статистику обновлю еще гляну позже

(127) В принципе все что выше написали по поводу регистра и индексации верно, если что пишите на мейл, поковыряю планы.

(127) Спасибо за участие и пожалуйста выложи просьбу в (117), моего запроса в (12) только с INNER JOIN чтобы сравнить с (0)

Господа, мне кажется подход неверный изначально. Делать запрос к документу - моветон. Изначально должен быть запрос к Оборотному регистру накопления ибо это продажи, ибо это документ РТУ. Если конфа ERP тогда запрос по оборотному регистру ВыручкаИСебестоимостьПродажОбороты

Если это УПП то там есть оборотный регистр накопления ПродажиСебестоимость, делай запрос к виртуальной таблице ПродажиСебестоимостьОбороты

(130) Да только там данных изначально больше, дефрагментация таблицы может быть больше, индексы толще( можно конечно уповать на то что они в кэше ) и всё равно из-за поля ПервыйРаз соединять с таблицей Документ.РеализацияТоваровУслуг так что не вижу причин почему запрос не сделать так как в (12)

(131) Нет комментариев я в ехере

Прискорбно, что большинство 1сников не знают 1С.

(132) Что мешает ВЫБРАТЬ ПЕРВЫЕ 1 ?

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

(132) Поля ПервыРаз быть не должно, если это костыль статуса, то такой статус должен хранится в Регистре сведений

(132) Да и вообще что это за признак, косвенный признак что это первая продажа данному контрагенту? Тогда можно обойтись и без него.

Попробуй переделать запрос на -
ВЫБРАТЬ
    Док.Ссылка КАК Ссылка
    Поместить ВТ_Документы
ИЗ
    Документ.РеализацияТоваровУслуг КАК Док
ГДЕ
    Док.Проведен
    И Док.Дата МЕЖДУ &ДатаНач И &ДатаКон
    И Док.ПервыйРаз;
    
ВЫБРАТЬ
    РеализацияТоваровУслугТовары.Номенклатура КАК Номенклатура,
    СУММА(РеализацияТоваровУслугТовары.Количество) КАК Количество
ИЗ
    Документ.РеализацияТоваровУслуг.Товары КАК РеализацияТоваровУслугТовары
ГДЕ
    РеализацияТоваровУслугТовары.Ссылка В (выбрать Т.Ссылка ИЗ ВТ_Документы КАК Т)

СГРУППИРОВАТЬ ПО
    РеализацияТоваровУслугТовары.Номенклатура

(139) по точке запятой предполагаю что это пакетный запрос, тогда не хватает ПОМЕСТИТЬ Т

но все это бред, какие то жалкие щенячие попытки реализовать поставленную задачу через костыли абы как

делать нужно как правильно, а не тупо абы как лишь бы взлетело

Читаем (131) (135) (136) (137) (138)

(143) Автор пиши исчо ( фильтр не пропускает точное изречение )

(139) ну так там есть Поместить ВТ_Документы,
и именно таким методом я ускорял запросы когда внутри ТЧ дофига строк и идут фильтры на Ссылка.

(145) Это не тот случай. Запрос в (12) и не нужно временных таблиц, тем более через IN РеализацияТоваровУслугТовары.Ссылка В (выбрать Т.Ссылка ИЗ ВТ_Документы КАК Т)

PS: Ужас какой-то...

(142) тут у (0) есть костыль, и хотят его оптимизировать (146) не ужас

(147) Не ужас будет в другом запросе, но не в данном случае

(148) аа, ты хочешь тоже самое, но без ВТ. Да, можно и так.

(149) Я написал запрос в (12) только там внетреннее соединение поставить и это конечный вариант.

(124) "Если у нас есть реквизит типа Булево, который мы проиндексировали с целью ускорить получение информации, то это будет очень неэффективно. Потому что Булево имеет всего два значения, и если они равномерно распределены в таблице, то половина таблицы будет со значениями Истина, а другая половина - со значениями Ложь. В результате СУБД не будет использовать такой индекс, потому что она увидит, что ничего полезного она от этого индекса не получит. Подобный индекс будет использоваться только в том случае, если мы хотим выбрать, например, значение Ложь, и записей с таким значением очень мало. Например, 99% это Истина, и 1% это Ложь."

(151) Прочитай (8) потом (12). Потом перечитай свой пост внимательно и пойми что нужно думать над каждой конкретной ситуацией, а не кричать что "индексы в конкретных случаях могут замедлять неожиданно".

(152) Умник, я не кричу,а лишь привел выдержку из статьи компании 1С, так для размышления.

(152) и тебе в догонку (122)

(154) Последние два предложения из своей выдержки перечитай. (122) это как раз о случае когда таких записей примерно поровну.

(155) Если записей примерно поровну, то прям в выдержке указано: "равномерно распределены в таблице, то половина таблицы будет со значениями Истина, а другая половина - со значениями Ложь. В результате СУБД не будет использовать такой индекс"

(155) да про 122 согласен.