СТАБИЛЬНАЯ производительность при поиске 1-1

Я использую запрос с функцией containstable со строковым поиском вроде этого: «1-1» или аналогичный (например, «1 1» или «aa»). Проблема в том, что запрос занимает слишком много времени и не дает много результатов. . Вместо этого тот же запрос, но с другой строкой поиска, такой как «a», которая дает гораздо больше результатов, и для ее выполнения требуется гораздо меньше времени. это запрос:

SELECT     COUNT(d.DocumentID) 
FROM       KnowledgeIndex_Data.dbo.Document d
INNER JOIN CONTAINSTABLE ( KnowledgeIndex_Data.dbo.Document , * , '"1-1"' ) ftt 
        ON ( d.DocumentID = ftt.[Key] )

Примечание. Список стоп-слов для полнотекстового индекса не содержит 1

Вы знаете, что может происходить? Спасибо!

Вот план выполнения

План

вот сценарий создания таблицы Document:

CREATE TABLE dbo.Document
(
      DocumentID int IDENTITY (1, 1) NOT NULL -- Local int for cross reference tables to save 12 bytes per record
    , DocumentGUID uniqueidentifier NOT NULL

--  , DocumentTypeID tinyint NOT NULL
    , DocumentSourceID smallint NOT NULL -- New Document Source identifier
    , SourceDocumentID nvarchar(80) NOT NULL --crb 2011/08/23 changed from nvarchar(40) to support PageCodes -- asw 2010/02/12 renamed to make purpose more clear

    , DocumentStructureID tinyint NOT NULL -- New Document Structure identifier

    , SortOrder nvarchar(450) NOT NULL -- 2010/06/18 bdw- Add the Sort Order column and index to the Document table

    , ResultDisplayContent xml (DOCUMENT DocumentResultDisplayContentSchemaCollection) NOT NULL  -- Required For All DocumentTypes -- jci 2011/02/22 DOCUMENT added -- jci 2010/07/02 xml schema added
    , DetailDisplayContent xml (DOCUMENT DocumentDetailDisplayContentSchemaCollection) NULL -- Only required for some DocumentTypes -- jci 2011/02/22 DOCUMENT added  -- jci 2011/0/31 xml schema added
    , TeaserDisplayContent xml (DOCUMENT DocumentResultDisplayContentSchemaCollection) NULL -- Teaser Result data. Optional, replaced with main ResultDisplayContent if null. -- jci 2011/02/22 DOCUMENT added -- jci 2010/07/02 xml schema added

, TitleQueryContent nvarchar(max) NOT NULL
, QueryContent nvarchar(max) NOT NULL

, CreatedAt datetimeoffset(2) NOT NULL

, CONSTRAINT pcDocument PRIMARY KEY CLUSTERED -- jci 2011/07/01 replaced -- CONSTRAINT pncDocument PRIMARY KEY NONCLUSTERED
    ( DocumentID ) WITH FILLFACTOR = 100
, CONSTRAINT fkDocumentDocumentSourceID FOREIGN KEY
    ( DocumentSourceID )
    REFERENCES dbo.DocumentSource ( DocumentSourceID )
    ON DELETE CASCADE
, CONSTRAINT fkDocumentDocumentStructureID FOREIGN KEY
    ( DocumentStructureID )
    REFERENCES dbo.DocumentStructure ( DocumentStructureID )
    ON DELETE CASCADE
)
GO

и индекс:

-- Create Index On Table
CREATE FULLTEXT INDEX ON dbo.Document(QueryContent LANGUAGE N'English' , TitleQueryContent LANGUAGE N'English')
    KEY INDEX pcDocument -- 2011/07/01 replaced --pncDocument
    ON (FILEGROUP SECONDARY)
    WITH STOPLIST = SrsStopWordList -- Use SrsStopWordList
        , CHANGE_TRACKING = OFF , NO POPULATION; -- Update Manually For Performance

GO

sql sql-server full-text-search containstable
person Gerardo Gonzalez    schedule 13.11.2012    source источник
comment
Какая версия SQL Server? Как выглядит план? Находится ли табличная функция contains внутри плана вложенных циклов, чтобы она повторно оценивалась?   -  person Martin Smith    schedule 14.11.2012
comment
Также в чем ваш вопрос. Вы спрашиваете о производительности или результатах?   -  person Martin Smith    schedule 14.11.2012
comment
Я использую SQLserver 2008. Да, вопрос в производительности, как она может быть такой медленной. Поскольку это не приносит много результатов Спасибо.   -  person Gerardo Gonzalez    schedule 14.11.2012
comment
Пожалуйста, опубликуйте план выполнения.   -  person Martin Smith    schedule 14.11.2012
comment
Какое определение для dbo.Document включая индексы? Как выглядит быстрый план?   -  person Martin Smith    schedule 14.11.2012
comment
Быстрый поиск плана для поискового механизма или занимает 10 секунд против 1 минуты 40 секунд, которые требуются для поиска 11, а план выполнения очень похож на   -  person Gerardo Gonzalez    schedule 14.11.2012

Ответы (2)


arrow_upward
0
arrow_downward

Запуск sys.dm_fts_parser по поисковому запросу приводит к следующему:

select  *from sys.dm_fts_parser('"1-1"', 1033, 0 ,0)

display_term    expansion_type  source_term
1                0       1-1
nn1              0       1-1
1                0       1-1
nn1              0       1-1

Таким образом, полнотекстовый движок выполняет поиск 4 различных условий поиска, а затем объединяет результаты. Не могли бы вы запустить sys.dm_fts_index_keywords в своей таблице с display_term LIKE '1' или 'nn1' и поделиться результатами? Это может помочь объяснить длительное время работы.

person aks    schedule 14.11.2012

arrow_upward
0
arrow_downward

Я сделал этот запрос следующим образом:

   SELECT count(*) FROM sys.dm_fts_index_keywords(db_id('KnowledgeIndex_Data'),              object_id('dbo.Document'))
   where display_term like '%1-1%'
   GO

он вернул 685053 с "% nn1%", вернул 413578 с "% engine%", он вернул 2500

Обратите внимание, что 1 - не шумное слово для моего полнотекстового индекса. Думаете, это может быть связано с этим?

Можно ли было бы выполнить CONTAINSTABLE с частью таблицы вместо всей таблицы?

CONATINSTABLE выполняет поиск по всей таблице dbo.Document, и фактически после этого запроса я применяю WHERE к полю документа, которое заставляет CONTAINSTABLE выполнять ненужную работу. Спасибо!

person Gerardo Gonzalez    schedule 14.11.2012