Oracle Text
1 – Výkon můžete zlepšit vytvořením indexu CONTEXT pomocí FILTER BY:
create index my_idx on my_table(text) indextype is ctxsys.context filter by group_id;
V mých testech filter by rozhodně zlepšil výkon, ale stále bylo o něco rychlejší použít pouze index btree na group_id.
2 - Indexy CTXCAT používají "podindexy" a zdá se, že fungují podobně jako index s více sloupci. Zdá se, že toto je možnost (4), kterou hledáte:
begin
ctx_ddl.create_index_set('my_table_index_set');
ctx_ddl.add_index('my_table_index_set', 'group_id');
end;
/
create index my_idx2 on my_table(text) indextype is ctxsys.ctxcat
parameters('index set my_table_index_set');
select * from my_table where catsearch(text, 'blah', 'group_id = 43') > 0
Toto je pravděpodobně nejrychlejší přístup. Použití výše uvedeného dotazu proti 120 MB náhodného textu podobného vašemu scénáři A a B vyžadovalo pouze 18 konzistentních get. Na druhou stranu však vytvoření indexu CTXCAT trvalo téměř 11 minut a zabralo 1,8 GB místa.
(Poznámka:Zdá se, že Oracle Text zde funguje správně, ale neznám text a nemohu zaručit, že se nejedná o nevhodné použití těchto indexů, jak řekl @NullUserException.)
Vícesloupcové indexy vs. spojení indexů
Pro situaci, kterou popisujete ve své úpravě, normálně nebyl by významný rozdíl mezi použitím indexu na (A,B) a spojením samostatných indexů na A a B. Vytvořil jsem několik testů s daty podobnými tomu, co jste popsali, a spojení indexu vyžadovalo pouze 7 konzistentních získání versus 2 konzistentní získání pro vícesloupcový index.
Důvodem je to, že Oracle načítá data v blocích. Blok má obvykle 8 kB a blok indexu je již setříděný, takže pravděpodobně můžete umístit hodnoty 500 až 2 000 do několika bloků. Pokud se obáváte o výkon, obvykle je IO pro čtení a zápis bloků jedinou věcí, na které záleží. Zda musí Oracle spojit několik tisíc řádků nebo ne, je nepodstatné množství času CPU.
To se však netýká indexů Oracle Text. Můžete spojit CONTEXT index s indexem btree ("bitmapa a"?), ale výkon je slabý.