Teljes szövegű keresés

A következőkre vonatkozik:SQL Server Azure SQL Database Azure SQL Managed Instance

Az SQL Serverben és az Azure SQL Database-ben a teljes szöveges kereséssel a felhasználók és alkalmazások teljes szöveges lekérdezéseket futtathatnak az SQL Server-táblákban lévő karakteres adatokon.

Breaking változások az SQL Server 2025-ben

Az SQL Server 2025 (17.x) a Full-Text Searcht érintő kompatibilitástörő változásokat vezet be.

További információkért lásd:

Alapműveletek

Ez a cikk áttekintést nyújt a Full-Text Keresésről, és ismerteti annak összetevőit és architektúráját. Ha szeretné azonnal megkezdeni az első lépéseket, itt találja az alapvető feladatokat.

Full-Text Keresés az SQL Server adatbázismotor választható összetevője. Ha az SQL Server telepítésekor nem választja ki a Teljes szöveges keresés lehetőséget, később hozzáadhatja a Telepítő ismételt futtatásával.

Áttekintés

A teljes szöveges indexek egy vagy több karakteralapú oszlopot tartalmaznak egy táblában. Ezek az oszlopok a következő adattípusok bármelyikével rendelkezhetnek: char, varchar, nchar, nvarchar, text, ntext, image, xml vagy varbinary(max) és FILESTREAM. Minden teljes szöveges index egy vagy több oszlopot indexel a táblázatból, és minden oszlop egy adott nyelvet használhat.

A teljes szöveges lekérdezések nyelvi keresést végeznek a szöveges adatokon teljes szöveges indexekben úgy, hogy egy adott nyelv szabályain ( például angol vagy japán) alapuló szavakon és kifejezéseken működnek. A teljes szöveges lekérdezések tartalmazhatnak alapvető szavakat és kifejezéseket, vagy több szó vagy kifejezés formáját. A teljes szöveges lekérdezés minden olyan dokumentumot visszaad, amely legalább egy egyezést (más néven találatot) tartalmaz. Egyezés akkor fordul elő, ha egy céldokumentum tartalmazza a teljes szöveges lekérdezésben megadott összes kifejezést, és megfelel minden más keresési feltételnek, például az egyező kifejezések közötti távolságnak.

Teljes szöveges keresési lekérdezések

Miután az oszlopokat hozzáadta egy teljes szöveges indexhez, a felhasználók és az alkalmazások teljes szöveges lekérdezéseket futtathatnak az oszlopok szövegén. Ezek a lekérdezések a következő feltételek bármelyikére kereshetnek:

Egy vagy több konkrét szó vagy kifejezés (egyszerű kifejezés)
Egy szó vagy kifejezés, amelyben a szavak megadott szöveggel kezdődnek (előtag kifejezés)
Adott szó inflektív formái (generációs kifejezés)
Egy másik szóhoz vagy kifejezéshez közeli szó vagy kifejezés (közelségi kifejezés)
Egy adott szó szinonimái (szinonimaszótár)
Súlyozott értékeket használó szavak vagy kifejezések (súlyozott kifejezés)

A teljes szöveges lekérdezések nem érzékenyek a kis- és nagybetűkre. Például a Aluminum vagy a aluminum keresése ugyanazokat az eredményeket adja vissza.

A teljes szöveges lekérdezések Transact-SQL predikátumok (CONTAINS és FREETEXT) és függvények (CONTAINSTABLE és FREETEXTTABLE) kis halmazát használják. Az adott üzleti forgatókönyv keresési céljai azonban befolyásolják a teljes szöveges lekérdezések szerkezetét. Például:

Termék keresése egy e-kereskedelmi webhelyen:

SELECT product_id
FROM products
WHERE CONTAINS ((product_description), '"Snap Happy 100EZ" OR FORMSOF(THESAURUS,"Snap Happy") OR "100EZ"')
      AND product_cost < 200;

A SQL Server végzett munkatapasztalattal rendelkező állásjelöltek keresése:

SELECT candidate_name,
       SSN
FROM candidates
WHERE CONTAINS ((candidate_resume), '"SQL Server"')
      AND candidate_division = 'DBA';

További információ: Lekérdezés Full-Text kereséssel.

Full-Text Keresési lekérdezések összehasonlítása a LIKE-predikátumhoz

A teljes szöveges kereséssel ellentétben a LIKE Transact-SQL predikátum csak karaktermintákon működik. Emellett a predikátum nem használható LIKE formázott bináris adatok lekérdezésére. Emellett a LIKE nagy mennyiségű strukturálatlan szöveges adat lekérdezése sokkal lassabb, mint az azonos adatokon végzett teljes szöveges lekérdezés. Egy LIKE lekérdezés több millió sornyi szöveges adaton percekig is eltarthat, mire eredményt ad. Ezzel szemben egy teljes szöveges lekérdezés csak másodperceket vagy kevesebbet vehet igénybe ugyanazon adatokhoz képest, attól függően, hány sor visszatér.

Full-Text Keresési architektúra

A teljes szöveges keresési architektúra a következő folyamatokból áll:

Az SQL Server folyamata (sqlservr.exe).
A szűrő daemon gazdagép folyamata (fdhost.exe).

Biztonsági okokból egy külön folyamat, az úgynevezett szűrő daemon host, betölti a szűrőket és a szóbontókat. A fdhost.exe folyamatot egy FDHOST indítószolgáltatás (MSSQLFDLauncher) hozza létre. Az FDHOST launcher szolgáltatási fiók biztonsági adatai alatt fut. Ezért az FDHOST indítószolgáltatásnak teljes szöveges indexeléshez és teljes szöveges lekérdezéshez kell futnia. A szolgáltatás fiókjának beállításáról információért lásd: A teljes szövegű Filter Daemon Launcher szolgáltatási fiók beállítása.

Ez a két folyamat tartalmazza a teljes szöveges keresési architektúra összetevőit. Az alábbi ábra összefoglalja ezeket az összetevőket és azok kapcsolatait. Az összetevőket az ábra után ismertetjük.

SQL Server-folyamat

A Database Engine folyamat a teljes szöveges kereséshez az alábbi komponenseket használja:

Összetevő	Leírás
Felhasználói táblák	Ezek a táblák tartalmazzák a teljes szöveges indexelendő adatokat.
Teljes szöveges adatgyűjtő	A teljes szöveges adatösszegyűjtő a teljes szöveges bejárási folyamatokkal működik. Felelős a teljes szöveges indexek ütemezéséért és vezetéséért, valamint a teljes szöveges katalógusok monitorozásáért is.
Szinonimaszótár-fájlok	Ezek a fájlok a keresési kifejezések szinonimáit tartalmazzák. További információ: Szinonimaszótárfájlok konfigurálása és kezelése Full-Text kereséshez.
Lekciólista objektumok	A stoplist objektumok olyan gyakori szavak listáját tartalmazzák, amelyek nem hasznosak a kereséshez. További információért lásd: Stopword és stoplisták konfigurálása és kezelése Full-Text kereséshez.
Database Engine lekérdezésfeldolgozó	A lekérdezésfeldolgozó SQL-lekérdezéseket fordít és hajt végre. Ha egy SQL-lekérdezés tartalmaz egy teljes szöveges keresési lekérdezést, a rendszer elküldi a lekérdezést a Full-Text motornak a fordítás és a végrehajtás során is. A lekérdezés eredménye megfelel a teljes szöveges indexnek.
Full-Text motor	Az Adatbázismotor teljes szövegű keresőmotorja teljes mértékben integrálva van a lekérdezésfeldolgozóval. A Full-Text motor lefordítja és végrehajtja a teljes szöveges lekérdezéseket. A lekérdezés végrehajtása során előfordulhat, hogy a Full-Text motor bemenetet kap a szinonimaszótárból és a stoplistából.
Indexíró (indexelő)	Az indexíró létrehozza az indexelt jogkivonatok tárolására használt struktúrát.
Szűrő démon kezelője	A szűrő démonkezelője felelős a Full-Text motorszűrő démongazda állapotának monitorozásáért.

A szűrődémon gazdafolyamata

A szűrődémon gazdagépe egy folyamat, amelyet a Full-Text motor indít el. A következő teljes szöveges keresési összetevőket futtatja, amelyek a táblákból származó adatok eléréséért, szűréséért és szótöréséért, valamint a szavak feltöréséért és a lekérdezés bemenetének lekéréséért felelősek.

A szűrődémon gazdagép összetevői a következők:

Összetevő	Leírás
Protokollkezelő	Ez az összetevő további feldolgozás céljából lekéri az adatokat a memóriából, és egy adott adatbázisban lévő felhasználói táblából fér hozzá az adatokhoz. Az egyik feladata, hogy adatokat gyűjtsön a teljes szövegben indexelt oszlopokból, és továbbítsa azokat a szűrődémon hostnak, amely szükség szerint szűrést és szóbontást alkalmaz.
Szűrők	Néhány adattípus szűrést igényel, mielőtt a dokumentumban szereplő adatokat teljes szövegben indexelhetné. Ezek az adattípusok közé tartoznak a varbinary(max), image vagy xml oszlopokban lévő adatok. Az adott dokumentumhoz használt szűrő a dokumentum típusától függ. Különböző szűrőket használnak például a Microsoft Word-dokumentumokhoz`.doc`, a Microsoft Excel-dokumentumokhoz`.xls` és az XML- (`.xml`) dokumentumokhoz. A szűrő szövegdarabokat húz ki a dokumentumból, eltávolítja a beágyazott formázást, és megőrzi a szöveget, valamint potenciálisan az információt a szöveg helyzetéről. Az eredmény szöveges információk adatfolyama. További információért lásd: Szűrők konfigurálása és kezelése.
Szótörők és gyökeresítők	A szóhatároló egy nyelvspecifikus összetevő, amely egy adott nyelv lexikális szabályai (szótörés) alapján keresi meg a szavak határait. Minden szótörés egy nyelvspecifikus ősösszetevőhöz van társítva, amely konjugálja az igéket, és inflekciós bővítéseket hajt végre. Indexeléskor a szűrő démonkiszolgáló szótörőt és tőszármaztatót használ egy adott táblázatoszlop szöveges adatainak nyelvi elemzéséhez. A teljes szöveges indexben a táblázatoszlophoz társított nyelv határozza meg, hogy melyik szóhatárolót és szótőelemzőt használják az oszlop indexeléséhez. További információkért lásd: A szóelválasztók és szótövezők konfigurálása és kezelése.

Az SQL Server 2012 (11.x) az amerikai angol (LCID 1033) és az Egyesült Királyság angol (LCID 2057) szóhatárolóinak és őselemeinek új verzióját telepíti. Az összetevők korábbi verziójára azonban válthat, ha meg szeretné őrizni az előző viselkedést. További információért lásd: Az amerikai és a brit angolhoz használt szótördelő módosítása.

Teljes szöveges keresés feldolgozása

A teljes szöveges keresést a Full-Text motor hajtja. A Full-Text motor két szerepkörrel rendelkezik: a támogatás indexelésével és a támogatás lekérdezésével.

Teljes szöveges indexelési folyamat

Amikor teljes szöveges populációt indítasz (más néven crawl), a Full-Text Engine nagy adatadagokat küld be memóriába, és értesíti a szűrő démonhosztolót. A kiszolgáló szűri és szavakra bontja az adatokat, majd fordított szólistákká alakítja őket. Az indexelő ezután kinyeri az átalakított adatokat a szólistákból, feldolgozza őket a stopszavak eltávolítása érdekében, és az egy köteghez tartozó szólistákat egy vagy több inverz indexbe menti.

Amikor az xml, varbinary(max) vagy képoszlopban tárolt adatokat indexel, a felületet megvalósító IFilter szűrő a megadott fájlformátum alapján bontja ki a szöveget (például Microsoft Word). Bizonyos esetekben a szűrőkomponensek megkövetelik, hogy a bináris adatokat a FTData\FilterData mappába írják, ahelyett, hogy közvetlenül a memórián keresztül streamelnék.

A feldolgozás részeként az összegyűjtött szöveges adatokat egy szóbontón keresztül küldik, hogy a szöveget különálló tokenekre vagy kulcsszavakra bontsa. A tokenizáláshoz használt nyelv az oszlop szintjén van megadva, vagy a szűrőösszetevő varbinary(max), kép- vagy XML-adatai között azonosítható.

További feldolgozás is végezhető a stopszavak eltávolítása és a tokenek normalizálása érdekében, mielőtt a tokeneket a teljes szöveges index egy töredékében tárolnák.

Amikor egy feltöltés befejeződik, elindul egy végső összevonási folyamat, amely az indextöredékeket egyetlen fő teljes szöveges indexszé egyesíti. Ez a folyamat jobb lekérdezési teljesítményt eredményez, mivel több indextöredék helyett csak a fő indexet kell lekérdezni, és jobb pontozási statisztikák használhatók a relevancia rangsorolásához.

Teljes szöveges lekérdezési folyamat

A lekérdezésfeldolgozó átadja a lekérdezés teljes szöveges részeit a Full-Text motornak feldolgozás céljából. A Full-Text motor szótörést végez, és szükség esetén szinonimaszótár-bővítést, származtatást, valamint zajszófeldolgozást is végrehajt. Ezután a lekérdezés teljes szöveges részei SQL-operátorok formájában jelennek meg, elsősorban streamelési táblaértékű függvényekként (STVF-ek). A lekérdezés végrehajtása során ezek az STVF-ek a fordított indexhez férnek hozzá a megfelelő eredmények lekéréséhez. Az eredmények vagy ezen a ponton lesznek visszaadva az ügyfélnek, vagy tovább dolgozzák őket, mielőtt visszakerülnének az ügyfélhez.

Teljes szöveges indexarchitektúra

A Full-Text motor a teljes szöveges indexekben található információkat teljes szöveges lekérdezések fordítására használja, amelyek gyorsan kereshetnek egy táblában bizonyos szavakat vagy szavak kombinációit. A teljes szöveges indexek egy adatbázistábla egy vagy több oszlopában tárolják a fontos szavakra és azok helyére vonatkozó információkat. A teljes szöveges index az SQL Server Full-Text motorja által létrehozott és karbantartott tokenalapú funkcionális indexek speciális típusa. A teljes szöveges index létrehozásának folyamata eltér más típusú indexek készítésétől. Ahelyett, hogy egy adott sorban tárolt értéken alapuló B-fastruktúrát hoznának létre, a Full-Text motor fordított, halmozott, tömörített indexstruktúrát épít az indexelt szöveg egyes tokenjeiből. A teljes szöveges index méretét csak annak a számítógépnek a rendelkezésre álló memóriaerőforrásai korlátozzák, amelyen az SQL Server-példány fut.

Az SQL Server 2008-tól kezdve (10.0.x) a teljes szöveges indexek integrálva vannak az adatbázismotorral, ahelyett, hogy a fájlrendszerben tartózkodnak, mint az SQL Server korábbi verzióiban. Egy új adatbázis esetén a teljes szöveges katalógus most már egy virtuális objektum, amely nem tartozik egyetlen fájlcsoporthoz sem. Ez csupán egy logikus fogalom, amely a teljes szövegű indexek csoportjára utal. Fontos azonban megjegyezni, hogy egy SQL Server 2005 (9.x) adatbázis frissítése során bármely teljes szöveges katalógushoz, amely adatfájlokat tartalmaz, új fájlcsoportot hoznak létre. További információkért lásd: A teljes szöveges keresés frissítése.

Minden táblázatnak csak egy teljes szöveges indexe lehet. Teljes szöveges indexet létrehozni egy táblán egyetlen, egyedi, nem null oszlopnak kell lennie. char, varchar, nchar, nvarchar, text, ntext, image, xml és varbinary(max) típusú oszlopokon teljes szöveges indexet hozhatsz létre. Amikor teljes szöveges indexet hozol létre egy oszlopon, amelynek adattípusa varbinary(max),image vagy xml, meg kell határoznod egy típusoszlopot. A típusoszlop egy táblaoszlop, amelyben a dokumentum fájlkiterjesztését (.doc, .pdfés .xlsígy tovább) tárolja minden sorban.

Teljes szöveges indexstruktúra

A teljes szöveges index szerkezetének alapos ismerete segít megérteni a Full-Text Motor működését. Ez a cikk a Document táblázat AdventureWorks2025 alábbi részletét használja példatáblaként. Ez a részlet csak két oszlopot, az DocumentID oszlopot és az Title oszlopot, valamint a táblázat három sorát jeleníti meg.

Ebben a példában tegyük fel, hogy a Title oszlopon teljes szövegű indexet hoztak létre.

Dokumentumazonosító	Cím
`1`	`Crank Arm and Tire Maintenance`
`2`	`Front Reflector Bracket and Reflector Assembly 3`
`3`	`Front Reflector Bracket Installation`

Például a következő táblázat, amely az 1. töredéket jeleníti meg, ábrázolja a Title oszlopon létrehozott teljes szöveges index tartalmát a Document táblázatban. A teljes szöveges indexek több információt tartalmaznak, mint amennyit a táblázat tartalmaz. A táblázat egy teljes szöveges index logikai ábrázolása, és csak szemléltetésre szolgál. A sorok tömörített formátumban vannak tárolva a lemezhasználat optimalizálása érdekében.

Az adatok megfordítva vannak az eredeti dokumentumokból. Az inverzió azért következik be, mert a kulcsszavakat a dokumentumazonosítókhoz rendelik. Ezért a teljes szöveges indexeket gyakran fordított indexnek is nevezik.

Azt is megfigyelheti, hogy a kulcsszó and el lesz távolítva a teljes szöveges indexből, mert and ez egy stopword. A stopwords teljes szöveges indexből való eltávolítása jelentős lemezterület-megtakarítást eredményezhet, ami javítja a lekérdezési teljesítményt. További információ a stopwordsről: Stopwords és stoplists konfigurálása és kezelése Full-Text Kereséshez.

Töredék 1

Kulcsszó	ColId	Dokumentumazonosító	Előfordulás
`Crank`	1	1	1
`Arm`	1	1	2
`Tire`	1	1	4
`Maintenance`	1	1	5
`Front`	1	2	1
`Front`	1	3	1
`Reflector`	1	2	2
`Reflector`	1	2	5
`Reflector`	1	3	2
`Bracket`	1	2	3
`Bracket`	1	3	3
`Assembly`	1	2	6
`3`	1	2	7
`Installation`	1	3	4

Az Keyword oszlop egyetlen, indexelési időpontban kinyert tokent tartalmaz. A szóelválasztók határozzák meg, hogy mi alkot egy tokent.

Az ColId oszlop egy olyan értéket tartalmaz, amely egy teljes szöveges indexelt oszlopnak felel meg.

Az DocId oszlop egy 8 bájtos egész szám értékeit tartalmazza, amelyek egy teljes szöveges indexelt táblázat adott teljes szöveges kulcsértékéhez lesznek leképezettek. Ez a leképezés akkor szükséges, ha a teljes szöveges kulcs nem egész adattípus. Ilyen esetekben a teljes szöveges kulcsértékek és DocId értékek közötti megfeleltetés egy külön táblában, a DocId Mapping táblában marad fenn. A leképezések lekérdezéséhez használja a sp_fulltext_keymappings rendszer által tárolt eljárást. A keresési feltétel DocId teljesítéséhez az előző tábla értékeit össze kell illeszteni a leképezési táblával a DocId lekérdezett alaptábla sorainak lekéréséhez. Ha az alaptábla teljes kulcsértéke egész szám típusú, akkor az érték közvetlenül szolgál DocId szerepében, és nincs szükség leképezésre. Ezért a teljes szöveges kulcsértékek egész számának használata segíthet a teljes szöveges lekérdezések optimalizálásában.

Az Occurrence oszlop egész számot tartalmaz. Minden DocId értékhez egy előfordulási értékeket tartalmazó lista tartozik, amelyek az adott kulcsszó relatív szópozícióit jelölik azon DocId-n belül. Az előfordulási értékek hasznosak a kifejezés- vagy közelségi egyezések meghatározásában, például a kifejezések numerikusan szomszédos előfordulási értékekkel rendelkeznek. Hasznosak a relevancia pontszámok számításában is. Például a kulcsszó előfordulásának száma a DocId pontozásban használható.

Teljes szöveges indextöredékek

A logikai teljes szöveges index általában több belső táblára oszlik. Minden belső táblázatot teljes szöveges indextöredéknek nevezünk. Ezen töredékek némelyike újabb adatokat tartalmazhat, mint mások. Például, ha egy felhasználó módosítja a következő sort, amelynek a DocId értéke 3, és a tábla automatikusan követi a módosításokat, akkor új fragmentum jön létre.

Dokumentumazonosító	Cím
`3`	`Rear Reflector`

A következő példában, amely a 2. töredéket mutatja, a töredék újabb adatokat tartalmaz a DocId 3-as részletről az 1-es töredékhez képest. Ezért amikor a felhasználó lekérdezi a Rear Reflector-t, a 2. fragmentum adatait használja a rendszer a(z) DocId 3-hoz. Minden töredék egy létrehozási időbélyeggel van megjelölve, amely lekérdezhető a sys.fulltext_index_fragments katalógusnézet használatával.

Töredék 2

Kulcsszó	ColId	Dokumentumazonosító	Előfordulás
`Rear`	1	3	1
`Reflector`	1	3	2

Ahogy a 2. töredékből is látható, a teljes szöveges lekérdezéseknek belsőleg kell lekérdeznie az egyes töredékeket, és el kell vetnie a régebbi bejegyzéseket. Ezért a teljes szöveges index túl sok teljes szöveges indextöredéke jelentős leromláshoz vezethet a lekérdezési teljesítményben. A fragmentumok számának csökkentése érdekében a teljes szöveges katalógusot REORGANIZE az Transact-SQL utasítás opciójával ALTER FULLTEXT CATALOG szervezzük újra. Ez az utasítás egy fő egyesítést hajt végre, amely egyetlen nagyobb töredékbe egyesíti a töredékeket, és eltávolítja az összes elavult bejegyzést a teljes szöveges indexből.

Az átrendezés után a példaindex a következő sorokat tartalmazza:

Kulcsszó	ColId	Dokumentumazonosító	Előfordulás
`Crank`	1	1	1
`Arm`	1	1	2
`Tire`	1	1	4
`Maintenance`	1	1	5
`Front`	1	2	1
`Rear`	1	3	1
`Reflector`	1	2	2
`Reflector`	1	2	5
`Reflector`	1	3	2
`Bracket`	1	2	3
`Assembly`	1	2	6
`3`	1	2	7

A teljes szöveges indexek és a normál SQL Server-indexek közötti különbségek

Teljes szöveges indexek	Normál SQL Server-indexek
Táblánként csak egy teljes szöveges index engedélyezett.	Táblánként több normál index engedélyezett.
Az adatok teljes szöveges indexekhez , úgynevezett populációkhoz való hozzáadása ütemezéssel vagy adott kéréssel kérhető, vagy automatikusan, új adatok hozzáadásával történhet.	Automatikusan frissül, amikor a rendszer beszúrja, frissíti vagy törli azokat az adatokat, amelyeken alapulnak.
Ugyanabban az adatbázisban csoportosítva egy vagy több teljes szöveges katalógusba.	Nincs csoportosítva.

A teljes szöveges keresés nyelvi összetevői és nyelvi támogatása

A teljes szöveges keresés több mint 50 különböző nyelvet támogat, például angolt, spanyolt, kínaiat, japánt, arabot, banglát és hindit. A támogatott teljes szöveges nyelvek teljes listáját a sys.fulltext_languages című témakörben találja. A teljes szöveges indexben található oszlopok mindegyike egy Microsoft Windows helyi azonosítóval (LCID) van összekapcsolva, amely egy olyan nyelvet képvisel, amelyet a teljes szöveges keresés támogat. Például az LCID 1033 az amerikai angolnak felel meg, az LCID 2057 pedig a brit angolnak. Minden támogatott teljes szöveges nyelvhez a Database Engine olyan nyelvi komponenseket biztosít, amelyek támogatják a teljes szöveges adatok indexelését és lekérdezését, amelyek az adott nyelven tárolódnak.

A nyelvspecifikus összetevők a következő elemeket tartalmazzák:

Összetevő	Leírás
Szótörők és gyökeresítők	A szóválasztók egy adott nyelv lexikális szabályai (szótörés) alapján találják meg a szóhatárokat. Minden szóelemző egy olyan szótövezőhöz van társítva, amely ugyanahhoz a nyelvhez konjugálja az igéket. További információkért lásd: A szóelválasztók és a szótövezők konfigurálása és kezelése.
Stoplisták	Rendelkezésre áll egy rendszer-stoplista, amely a stopwords (más néven zajszavak) alapszintű készletét tartalmazza. A stopword olyan szó, amely nem segít a keresésben, és a teljes szöveges lekérdezések figyelmen kívül hagyják. Például az angol nyelvhelynél olyan szavak, mint a `a`, `and`, `is`, és `the` megállítószavaknak minősülnek. Általában egy vagy több szinonimaszótárfájlt és stoplistát kell konfigurálnia. További információért lásd: Stopword és stoplisták konfigurálása és kezelése Full-Text kereséshez.
Szinonimaszótár-fájlok	A Database Engine minden teljes szövegű nyelvhez egy szótárfájlt telepít, valamint egy globális szótár fájlt is. A telepített szinonimaszótárfájlok üresek, de szerkesztheti őket egy adott nyelv vagy üzleti forgatókönyv szinonimáinak definiálásához. A teljes szöveges adatokra szabott szinonimaszótár fejlesztésével hatékonyan bővítheti az adatokra vonatkozó teljes szöveges lekérdezések hatókörét. További információ: Szinonimaszótárfájlok konfigurálása és kezelése Full-Text kereséshez.
Szűrők (IFilterek)	Ha egy dokumentumot varbinary(max), image vagy xml adattípusú oszlopban indexel, szűrőre van szükség a további feldolgozáshoz. A szűrőnek a dokumentum típusára (`.doc`, , `.pdf`, `.xls.xml`stb.) kell vonatkoznia. További információért lásd: Szűrők konfigurálása és kezelése.

Visszajelzés

Hasznosnak találta ezt az oldalt?

Last updated on 2026-07-21