кусок кодика

    |WHERE isfolder=2 and ismark <> '*'
    |AND id in (select val from СписокТоваров)
    |AND id NOT in (select val from СписокИсключаемыхТоваров)

или лучше предварительно СписокТоваров очистить от СписокИсключаемыхТоваров?

|AND
( id in (select val from СписокТоваров)
    |OR id NOT in (select val from СписокИсключаемыхТоваров))

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

(1) а че OR-то?

Зависит скорее всего от размера списка исключаемых товаров.
Скорее всего, особой разницы по времени выполнения не будет. Однако зависит еще и от версии sqlite. Вроде видел на 1С++ форуме - кто-то подхватил разработку и выпускает версии с более свежим sqlite.

(3) + - вон оно че... не разобрался сразу :)

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

(5)
to be or not to be :)

(0) "авторский" 1sqlite, емнип, не использует индекс для in

(8) и что? не заморачиваться с 1sqlite? решать методами 1с?

вообще говоря я, скорее всего, гланды рву через ж. :)

тут я получаю СписокИсключаемыхТоваров
    текст="SELECT
    |ParentExt [Владелец :Справочник.Отделы],    
    |Спр.Товар [Товар :Справочник.Номенклатура]
    |FROM [Справочник.ТоварыПоОтделам] Спр
    |WHERE ismark <> '*'
    |AND ParentExt in СписокОтдел
    |Group by ParentExt, Спр.Товар";

а тут уже его использую

    текст="SELECT
    |id [Товар :Справочник.Номенклатура],
    |code Код
    |FROM Товары
    |WHERE isfolder=2 and ismark <> '*'
    |AND id in (select val from СписокТоваров)
    |AND id NOT in (select val from СписокИсключаемыхТоваров)";

наверное это можно сделать в одном запросе?

(8)
Не "авторских 1sqlite не использует", а "sqlite для виртуальных таблиц не использует" :)
Чтобы использовал, надо запрос переписывать:
select ... from СписокТоваров left join Справочник_Номенклатура on val=id
Правда, не всегда использование индекса оправдано в этом случае. Если список большой - проще раз по таблице пробежаться и проверить вхождение в список, чем кучу раз по индексу скакать.

(10) а что оптимизатора в склайт нет? )))

(11)
Есть. Но для своих таблиц. А к 1Совским он через механизм "виртуальных таблиц" стучится, которые менее оптимизируемы.
Собственно, sqlite совершенно ничего не знает ни про дбф, ни про индексы к нему. Это моя компонента обеспечивает.

+(12)
http://sqlite.org/optoverview.html
http://sqlite.org/queryplanner-ng.html

(10) доработанный Djelf'ом уже использует, но там и движок унутре уже другой версии)
(9) как уже написали, можно загонять список в отдельную таблицу и делать джойн

(4) Да, пытаюсь обновлять до текущей версии.
Низкий поклон за открытый код! Сделанный объем работ для прикручивания к 1с просто ужасает. Внешние базы sqlite прямо панацея для файловой 7ки в случаи всяких интеграций, не знаю как бы я по другому выкручивался!

(0) С in поаккуратнее, он нормально работает только на движке sqlite 3.8.+, на движке 3.7.17 как оказалось глючит, а на более старых версиях тормоза почти обеспечены т.к. индекс не использует.

Дал бы ссылки, но ветка на 1с++ по sqlite сломалась, и пароль тоже сломался и не приходит на newmail.ru.

Вот последняя моя сборка на движке sqlite 3.8.11.1  https://cloud.mail.ru/public/CYZn/cSN7ivTNe
Там пара микрофиксов к 1sqlite (типизация неопределенного значения длиной 23, и что то еще), и слегка изменен планировщик 1sqlite для более адекватного поведения в 3.8.11
Но если 1sqlite 1.0.2.4 работает, то лучше не трогать ;)

Планировщик в 3.8.11+ иногда строит безумные планы запросов.
Это решаемо, но разница в скорости может быть в 100-1000 раз.

P.S. 3.8.11+ потому что в 3.8.0 был сломан планировщик для виртуальных таблиц (читаем таблиц 1с), а в 3.8.11 его починили.

(16) Спасибо за поддержание допрасширений клюшек! как бы мы без них..

(15)
Тебе спасибо!
Всегда радует, что хоть кто-то смог разобраться в твоем коде :) А то иногда сам через пол-года уже не понимаешь, что написал.