Оптимальный индекс SQL Server для подстроки?

Question

Под управлением SQL Server 2008 у меня есть таблица с несколькими миллионами строк журнала данных из приложения.Я пытаюсь выяснить, как написать лучший индекс, чтобы получить соответствующую информацию.

Таблица выглядит следующим образом.Просто пример, фактические данные сообщения длинные.

CREATE TABLE #Info(
    [infoID] [int] IDENTITY(1,1) NOT NULL,
    [ActionHappened] [datetime] NOT NULL,
    [PartialMessage] [nvarchar](1500) NULL,
    [FullMessage] [nvarchar](max) NULL,
 CONSTRAINT [pk_info] PRIMARY KEY CLUSTERED([infoID] ASC)
      WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE  = OFF, IGNORE_DUP_KEY = OFF, 
            ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY] ) ON [PRIMARY]

Insert Into #Info Values ( GETDATE() , 'Thread:05;D:Start;Msg:Activity A' , 'Thread:05;D:Start;Msg:Activity A abcdegghijklmnopqrstuvwxyvabcdegghijklmnopqrstuvwxyvabcdegghijklmnopqrstuvwxyvabcdegghijklmnopqrstuvwxyvabcdegghijklmnopqrstuvwxyvabcdegghijklmnopqrstuvwxyvabcdegghijklmnopqrstuvwxyvabcdegghijklmnopqrstuvwxyvabcdegghijklmnopqrstuvwxyvabcdegghijklmnopqrstuvwxyvabcdegghijklmnopqrstuvwxyv' )
Insert Into #Info Values ( dateadd( minute , 3 , GETDATE() ) , 'Thread:05;D:Start;Msg:Activity B' , 'Thread:05;D:Start;Msg:Activity B abcdegghijklmnopqrstuvwxyvabcdegghijklmnopqrstuvwxyvabcdegghijklmnopqrstuvwxyvabcdegghijklmnopqrstuvwxyvabcdegghijklmnopqrstuvwxyvabcdegghijklmnopqrstuvwxyvabcdegghijklmnopqrstuvwxyvabcdegghijklmnopqrstuvwxyvabcdegghijklmnopqrstuvwxyvabcdegghijklmnopqrstuvwxyvabcdegghijklmnopqrstuvwxyv' )
Insert Into #Info Values ( dateadd( minute , 6 , GETDATE() )  , 'Thread:05;D:Start;Msg:Activity C' , 'Thread:05;D:Start;Msg:Activity D abcdegghijklmnopqrstuvwxyvabcdegghijklmnopqrstuvwxyvabcdegghijklmnopqrstuvwxyvabcdegghijklmnopqrstuvwxyvabcdegghijklmnopqrstuvwxyvabcdegghijklmnopqrstuvwxyvabcdegghijklmnopqrstuvwxyvabcdegghijklmnopqrstuvwxyvabcdegghijklmnopqrstuvwxyvabcdegghijklmnopqrstuvwxyvabcdegghijklmnopqrstuvwxyv' )
Insert Into #Info Values ( dateadd( minute , 9 , GETDATE() )  , 'Thread:05;D:Start;Msg:Activity D' , 'Thread:05;D:Start;Msg:Activity E abcdegghijklmnopqrstuvwxyvabcdegghijklmnopqrstuvwxyvabcdegghijklmnopqrstuvwxyvabcdegghijklmnopqrstuvwxyvabcdegghijklmnopqrstuvwxyvabcdegghijklmnopqrstuvwxyvabcdegghijklmnopqrstuvwxyvabcdegghijklmnopqrstuvwxyvabcdegghijklmnopqrstuvwxyvabcdegghijklmnopqrstuvwxyvabcdegghijklmnopqrstuvwxyv' )
Insert Into #Info Values ( dateadd( minute , 15 , GETDATE() )  , 'Thread:05;D:Start;Msg:Activity E' , 'Thread:05;D:Start;Msg:Activity F abcdegghijklmnopqrstuvwxyvabcdegghijklmnopqrstuvwxyvabcdegghijklmnopqrstuvwxyvabcdegghijklmnopqrstuvwxyvabcdegghijklmnopqrstuvwxyvabcdegghijklmnopqrstuvwxyvabcdegghijklmnopqrstuvwxyvabcdegghijklmnopqrstuvwxyvabcdegghijklmnopqrstuvwxyvabcdegghijklmnopqrstuvwxyvabcdegghijklmnopqrstuvwxyv' )

Мне нужно выбрать из PartialMessage, игнорируя все до второй точки с запятой, а затем вернуть ActionHappened и FullMessage.Например, я хочу

select ActionHappened, FullMessage 
from #Info 
where PartialMessage Like '%Activity D%'

, но, конечно, не сканирование таблицы и программный поиск внутри каждого столбца.

Все идеи приветствуются.

Спасибо.

Answer 1

Не могли бы вы создать индексированное представление для разделения полей, как предлагает Мартин?Следующее может работать, но с размером поля это может быть не выгодно.

• Создать поле с именем ReversePartialMessage
• Использование триггера для заполненияэто поле с полями REVERSE (partMessage)
• Добавить индекс для обоих полей PartialMessage и ReversePartialMessage

• Сделайте предложение WHERE

  где PartialMessage как 'Activity D%' и ReversePartialMessage как 'D ytivitcA%'

Однако, с размером PartialMessage я не уверенесли бы усилие этих индексов сильно улучшилось бы.Если поле может быть сокращено, эти индексы могут быть практичными.Если вы создаете индексы, обязательно посетите план выполнения, чтобы увидеть, действительно ли они используются.Оптимизатор может решить, что сканирование таблицы более эффективно, чем индексы.Работа по объединению выходных данных двух индексов, особенно с такими большими значениями ключа, может не дать сколько-нибудь значительных преимуществ ...