Azure SQL slow performance

Question

Краткая сводка моей проблемы: в моем экземпляре Azure SQL S0 требуется 8:57 минут для выполнения SELECT WHERE ColumnXYZ = '% anything%' в таблице с 8 211 037 строк (набор результатов = 929 строк) , На столе с 500 000 строк требуется 38 секунд. Та же таблица на моем ноутбуке (быстрый с SSD) с 8-метровыми линиями занимает 0 секунд.

Я понимаю, что может быть разница из-за спецификаций, но я не понимаю огромную разницу - эти уровни производительности не позволят мне использовать Azure SQL (мой db будет использоваться одним одновременным пользователь запускает отдельные запросы). Кроме того, я осторожен, чтобы перейти на более высокий уровень, потому что мне не нужно, чтобы DB была в два или четыре раза быстрее - она ​​должна быть в 500 раз быстрее. Любые идеи, если я что-то делаю неправильно? Или более быстрые результаты просто невозможны в Azure SQL Standard Tiers? Премиум-уровни не были бы экономически эффективными для меня, так как БД большую часть времени простаивала. Я не эксперт по БД, но я попытаюсь предоставить некоторые соответствующие подробности ниже - пожалуйста, сообщите, если я должен добавить более подробную информацию.

Таблица схемы:

CREATE TABLE [dbo].[TestTable](
    [ID] [int] IDENTITY(1,1) NOT NULL, 
    [PartNumber] [nvarchar](50) NULL, 
    [Name] [nvarchar](450) NULL, 
    [ProgramName] [nvarchar](450) NULL, 
    [URL] [nvarchar](450) NULL, 
    [ProgramNumber] [nvarchar](450) NULL, 
    [Date] [datetime] NULL, 
PRIMARY KEY CLUSTERED 
(
    [ID] ASC 
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) 
) 

некластерированных индексы на PARTNUMBER, имя, ProgramName. ProgramNumber. Кластерный индекс по ID.

Запрос:

SELECT [PartNumber] 
     ,[Name] 
     ,[ProgramName] 
     ,[URL] 
     ,[ProgramNumber] 
     ,[Date] 
    FROM [dbo].[TestTable] 
    where ProgramName like '%test%' 

план выполнения (Установить SHOWPLAN_ALL ON), первый столбец:

[removed original query as it takes up too much space 
    |--Nested Loops(Inner Join, OUTER REFERENCES:([db1].[dbo].[TestTable].[ID], [Expr1002]) OPTIMIZED WITH UNORDERED PREFETCH) 
     |--Index Scan(OBJECT:([db1].[dbo].[TestTable].[IX_TestTable_ProgramName]), WHERE:([db1].[dbo].[TestTable].[ProgramName] like N'%test%')) 
     |--Clustered Index Seek(OBJECT:([db1].[dbo].[TestTable].[PK__TableVie__3214EC277B422279]), SEEK:([db1].[dbo].[TestTable].[ID]=[db1].[dbo].[TestTable].[ID]) LOOKUP ORDERED FORWARD) 

Выполнение плана (Установить SHOWPLAN_ALL ON), другие столбцы:

EstimateRows EstimateIO EstimateCPU AvgRowSize TotalSubtreeCost 
28671.36 NULL NULL NULL 181.9502 
28671.36 0 0.1198463 3281 181.9502 
28671.36 73.67498 9.032298 2015 82.70728 
1 0.003125 0.0001581 1275 91.89737 

БД является в разработке, поэтому нет других пользователей/запросов. На панели Azure Portal Dashboard я вижу, что пик DTU сегодня (когда я тестировал) составлял 68,01%, поэтому емкость DTU, похоже, не проблема. Регион: Восток США

Я действительно застрял на этом - любая помощь очень приветствуется! Есть ли что-то, что я могу сделать, чтобы улучшить свой запрос? Или я должен рассмотреть другого поставщика облака (с MySQL)?

Answer 1

Запрос дорогой для выполнения из-за оператора LIKE, который вы используете в предложении where. В основном, БД должна смотреть на все записи в таблице, чтобы выяснить, которые являются частью набора результатов. Если это типичный запрос для вашего приложения, вам, вероятно, придется перейти на повышение до более высокого уровня производительности.

Если вы можете предсказать, когда выполняются запросы, вы можете перейти на более высокий уровень производительности для этих конкретных моментов времени, а затем впоследствии понизить базу данных. Таким образом вы можете использовать часовую биллинг, который имеет база данных SQL.

Answer 2

попробуйте функцию поиска в лазурном режиме, это улучшит работу поискового запроса.

http://azure.microsoft.com/en-us/documentation/services/search/