Oracle-tekst
1 - U kunt de prestaties verbeteren door de CONTEXT-index te maken met FILTER BY:
create index my_idx on my_table(text) indextype is ctxsys.context filter by group_id;
In mijn tests de filter by de prestaties zijn zeker verbeterd, maar het was nog steeds iets sneller om gewoon een btree-index op group_id te gebruiken.
2 - CTXCAT-indexen gebruiken "subindexen" en lijken op een index met meerdere kolommen te werken. Dit lijkt de optie (4) te zijn die u zoekt:
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
Dit is waarschijnlijk de snelste aanpak. Het gebruik van de bovenstaande query tegen 120 MB willekeurige tekst, vergelijkbaar met uw A- en B-scenario, vereist slechts 18 consistente resultaten. Maar het nadeel was dat het maken van de CTXCAT-index bijna 11 minuten duurde en 1,8 GB aan ruimte in beslag nam.
(Opmerking:Oracle Text lijkt hier correct te werken, maar ik ben niet bekend met Text en ik kan niet garanderen dat dit geen ongepast gebruik van deze indexen is, zoals @NullUserException zei.)
Indexen met meerdere kolommen versus indexkoppelingen
Voor de situatie die u beschrijft in uw bewerking, normaal gesproken er zou geen significant verschil zijn tussen het gebruik van een index op (A,B) en het samenvoegen van afzonderlijke indexen op A en B. Ik heb een aantal tests gebouwd met gegevens die vergelijkbaar zijn met wat je hebt beschreven en een index-join vereist slechts 7 consistente krijgt versus 2 consistente krijgt voor de index met meerdere kolommen.
De reden hiervoor is dat Oracle data in blokken ophaalt. Een blok is meestal 8K en een indexblok is al gesorteerd, dus je kunt waarschijnlijk de 500 tot 2000 waarden in een paar blokken passen. Als je je zorgen maakt over de prestaties, is meestal de IO om blokken te lezen en te schrijven het enige dat telt. Of Oracle wel of niet een paar duizend rijen moet samenvoegen, is een onbelangrijke hoeveelheid CPU-tijd.
Dit geldt echter niet voor Oracle Text-indexen. U kunt deelnemen aan een CONTEXT-index met een btree-index (een "bitmap en"?), maar de prestatie is slecht.