2kiruha
Странно как-то все.
Упростил запрос до такого:
SELECT
Товар,
sum(1)
from Регистр_Скидки
group by Товар
Детальный анализ программы выполнения с "group by +Товар", без использования индекса.
Открывается временный индексированный курсор (OpenEphemeral).
Выбираются записи из таблицы регистра, укладываясь в этот курсор в виде полей "Товар", счетчик строк, "Товар" :
VColumn 0 7 // Извлечение колонки "Товар"
Sequence 1 0 // Получение счетчика строк
VColumn 0 7 // Извлечение колонки "Товар"
MakeRecord 3 0 // Создание записи
IdxInsert 1 0 // Вставка созданной записи в курсор.
После выборки всех записей, временный курсор перемещается в начало выборки:
Sort
Потом идет выборка строк из временного курсора (индексированного по "Товар") и сравнение ключа - нулевой колонки (где лежит Товар) с предыдущим значением ключа. Если равно, то агрегирует, если не равно, выдает очередную строку готового результата.
Если же вариант с "group by Товар" (с использованием индекса), то просто не делается выгрузка во временный индексированный курсор. Выбираются записи из регистра, упорядоченные по "Товар", производится сравнение с предудущим значением ключа, если равны, то агрегируется, если не равны, выдает очередную строку результата.
На первый взгляд все верно.
Что при вставке в индекс, что при сравнении ключей используется BINARY сравнение, то бишь memcmp.
Единственно возможный вариант расхождений в результатах - если порядок сортировки в родном индексе не совпадает с порядком сортировки в SQLite.
Можешь попробовать сравнить результаты двух таких запросов:
SELECT
Товар
from Регистр_Скидки
order by Товар
и
SELECT
Товар
from Регистр_Скидки
order by +Товар
То бишь первый запрос выдаст строки в порядке следования их в индексе dbf-файла, а второй - упорядоченные самим SQLite'ом. Будет ли разница между ними?