Очень медленно Linq to SQL выбирает производительность на WP7 - PullRequest
2 голосов
/ 01 ноября 2011

У меня проблема с производительностью Linq to SQL на Windows Phone 7, но я действительно не уверен, что делаю неправильно (у меня почти нет опыта работы с Linq to SQL, и чем больше я читаю, тем в замешательстве я получаю вздох ).

Фон

У меня есть локальная база данных SQL CE с пятью таблицами, двумя столбцами в каждой (int первичный ключ и nvarchar значение плюс индексы) и около 100 000 записей в каждой таблице. Размер БД составляет около 20 МБ и реализован в соответствии с рекомендациями, приведенными в примере локальной базы данных MVVM от Microsoft.

Задача

После максимально возможного упрощения у меня в модели представления появился запрос, который выглядит следующим образом:

var query =
(
  from t1 in db.table1
    join t2 in db.table2 on t1.id equals t2.id
    join t3 in db.table3 on t1.id equals t3.id
    join t4 in db.table4 on t1.id equals t4.id
    join t5 in db.table5 on t1.id equals t5.id
  where
    SqlMethods.Like(t5.value, "%"+searchTerm+"%")
  select new Results
  {
    Field1 = t1.value,
    Field2 = t2.value,
    Field3 = t3.value,
    Field4 = t4.value,
    Field5 = t5.value,
  }
).Take(100);

SearchResults = new ObservableCollection<Results>(query);

Этот продукт следующий SQL:

SELECT TOP (100)
  [t0].[value] AS [Field1],
  [t1].[value] AS [Field2],
  [t2].[value] AS [Field3],
  [t3].[value] AS [Field4],
  [t4].[value] AS [Field5]
FROM
  [table1] AS [t0],
  [table2] AS [t1],
  [table3] AS [t2],
  [table4] AS [t3],
  [table5] AS [t4]
WHERE ([t4].[value] LIKE @p0)
  AND ([t0].[id] = [t4].[id])
  AND ([t0].[id] = [t3].[id])
  AND ([t0].[id] = [t2].[id])
  AND ([t0].[id] = [t1].[id])

Проблема в том, что, если поисковый термин очень специфичен (только один результат), его выполнение в среднем составляет 5 секунд . Это до того, как я добавлю какие-либо другие требования, например, несколько выражений where, ранжирование, упорядочение и т. Д. Даже если я ищу то, что, как я знаю, является первой строкой в ​​базе данных, это все равно занимает около 5 секунд.

Если я изменяю подход и ищу что-то очень распространенное (например, 'the'), для выполнения требуется всего 100ms . Я знаю, что Like с подстановочными знаками сложнее, чем прямое == сравнение, но я не знаю, почему производительность так отличается.

(Я знаю, что это бесполезное сравнение, так как это яблоки и апельсины, но ранее я выполнял похожие запросы в одной и той же базе данных, написанной на MySQL, и они последовательно получали результаты в течение 0,3-0,4 с независимо от того, что я искал ).

Я что-то упускаю действительно очевидное? Я следовал примеру Microsoft и прочитал много учебников в Интернете, но не могу найти причину, почему этот запрос такой медленный. Заранее большое спасибо за любые советы, которые вы можете предложить.

1 Ответ

3 голосов
/ 01 ноября 2011

ПРОСТОЙ ОБЩИЙ СМЫСЛ.

  • Вы запускаете это на телефоне с низким энергопотреблением и делаете запрос сканирования таблицы.

SqlMethods.Like (t5.value, "%" + searchTerm + "%")

означает отсутствие захватов индекса, это сканирование таблицы.

). Take (100);

Означает: остановка после того, как найдены 100 элементов.

Теперь, с очень распространенным словом ("the"), это может означать, что обрабатывается только 100 элементов.С более необычным словом, возможно, придется пробежать половину таблицы, чтобы получить 100 предметов.Сканирование таблицы на половину этой базы данных займет время.Simlpe.

В общем, sql плохо подготовлен для разбора слов в текстах - вот почему настоящий сервер sql имеет полнотекстовую индексацию.Выполнение этого (% word%) на оборудовании с низким уровнем громкости (wp7 = естественно медленно).

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...