медленные запросы - используют взгляды

Question

BACKEND на облаке с помощью SQL Server Express 2008 R2 Frontend на Access 2013

У меня был запрос, который я недавно должен был добавить подзапрос, чтобы ограничить результаты. Для выполнения запроса потребовалось около 1 секунды, но теперь он занимает около 70+. Я думаю, проблема может заключаться в том, что я использую представления в запросе, которые не индексируются. Я довольно новичок в этом и не очень часто использую Access/SQL, поэтому извиняюсь, если мне не хватает чего-то очевидного здесь.

Это мой код запроса:

SELECT DISTINCT vuSearch.PAID 
    ,vuSearch.PDID 
    ,ConcatAddress(Nz([Building_Name]), Nz([Building_No]), Nz([Street]), Nz([IndEst]), Nz([District]), Nz([Town]), Nz([Postcode])) AS Address 
    ,vuSearch.Deal_Date 
    ,vuSearch.Lease_End 
    ,vuSearch.Break_Date 
    ,vuSearch.Review_Date 
    ,vuSearch.PropertyType 
    ,vuSearch.Acting_For 
    ,vuSearch.Landlord_Seller 
    ,vuSearch.Tenant_Purchaser 
    ,IIf(IsNull([vuSearch.GIA]), [vuSearch.NIA], [vuSearch.GIA]) AS MainArea 
    ,vuDesc.Comments_Incentives 
    ,tldDealSearch.Include 
    ,vuSearch.Incomplete 
FROM (
    vuSearch RIGHT JOIN tldDealSearch ON vuSearch.PDID = tldDealSearch.PDID 
    ) 
LEFT JOIN vuDesc ON tldDealSearch.PDID = vuDesc.PDID 
WHERE (
     (
      (vuSearch.PDID) IN (
       (
        SELECT Max(v2.PDID) 
        FROM vuSearch AS v2 
        GROUP BY v2.PAID 
        ) 
       ) 
      ) 
     AND ((vuSearch.Incomplete) = False) 
     );

Я добавил индексы в таблицу tldDealSearch для PDID и включать поля (я думаю, что я сделал это право). Когда я смотрел на представления на бэкэнд, я не мог добавлять индексы, поскольку представления не связаны с привязкой к схеме.

Есть ли что-нибудь, что я могу сделать или должен смотреть, чтобы ускорить это? Я очень волнуюсь, так как сейчас в базе данных всего 300 записей - 70 + секунд?

Я проверил все на инструменте «Анализ производительности», но не уверен, что делать дальше.

EDIT: Спасибо за быстрые ответы ребята.

NZ - Это функция доступа NullToZero, на которую я верю, или что ее заменили.

ConcatAddress - это функция, которую я использую для объединения всех элементов адреса в читаемом формате для включения в отчет.

Public Function ConcatAddress(strBuildingName As String, strBuildingNo As String, strStreet As String, _ 
strIndEstate As String, strDistrict As String, strTown As String, strPostcode As String) As String 
    On Error GoTo ErrRoutine 
    Dim strSQL As String 
    If Len(strBuildingName) > 0 Then 
     strSQL = strBuildingName 
    End If 
    If Len(strBuildingNo) > 0 Then 
     If Len(strSQL) > 0 Then 
      strSQL = strSQL & " " & strBuildingNo 
     Else 
      strSQL = strBuildingNo 
     End If 
    End If 
    If Len(strStreet) > 0 Then 
     If Len(strSQL) > 0 Then 
      strSQL = strSQL & " " & strStreet & "," 
     Else 
      strSQL = strStreet 
     End If 
    End If 
    If Len(strIndEstate) > 0 Then 
     If Len(strSQL) > 0 Then 
      strSQL = strSQL & " " & strIndEstate & "," 
     Else 
      strSQL = strIndEstate 
     End If 
    End If 
    If Len(strDistrict) > 0 Then 
     If Len(strSQL) > 0 Then 
      strSQL = strSQL & " " & strDistrict & "," 
     Else 
      strSQL = strDistrict 
     End If 
    End If 
    If Len(strTown) > 0 Then 
     If Len(strSQL) > 0 Then 
      strSQL = strSQL & " " & strTown 
     Else 
      strSQL = strTown 
     End If 
    End If 
    If Len(strPostcode) > 0 Then 
     If Len(strSQL) > 0 Then 
      strSQL = strSQL & " " & strPostcode 
     Else 
      strSQL = strPostcode 
     End If 
    End If 
    If Len(strSQL) > 0 Then 
     ConcatAddress = strSQL 
    Else 
     ConcatAddress = "" 
    End If 
ErrExit: 
    Exit Function 
ErrRoutine: 
    ConcatAddress = Empty 
    Select Case Err 
     Case 94 
      'MsgBox "Postcode not found." 
      Resume ErrExit 
     Case Else 
      MsgBox "The following error has occurred " & Err & " " & Err.Description 
      Resume ErrExit 
    End Select 
End Function

'#' # '#' # '#' #»

EDIT

меня попросили опубликовать план выполнения запроса, но не доступен в доступе. У меня есть работа с взломом, которая, как мне кажется, близка к тому, что представляет собой план выполнения (не мог заставить его работать с Access 2013, хотя).

[Для информации] Добавить ключ и строку в реестре - HKEY_LOCAL_MACHINE \ SOFTWARE \ Wow6432Node \ Microsoft \ Jet \ 4.0 \ Engines
Добавить ключ 'Debug' и добавить строку 'JETSHOWPLAN' - Установите значение ON для записи (результаты должны быть в моих документах или в месте базы данных)

- Inputs to Query - 
ODBC table 'vuSearch' 
ODBC table 'vuSearch' 
Table 'tldDealSearch' 
ODBC table 'vuDesc' 
- End inputs to Query - 

01) Sort table 'vuDesc' 
02) Outer Join table 'tldDealSearch' to result of '01)' 
     using temporary index 
     join expression "tldDealSearch.PDID=vuDesc.PDID" 
1614631268) Remote SQL 
03) Sort result of '02)' 
04) Inner Join result of '02)' to result of '03)' 
     using temporary index 
     join expression "tldDealSearch.PDID=vuSearch.PDID" 
     store result in temporary table

Кажется много сортировки происходит так, что должно замедлить некоторые из них. Надеюсь, это то, что вы искали.

EDIT
Доступ JETSHOWPLAN не дает много деталей, поэтому я передал таблицу tldSearchData в бэкэнд и побежал запрос туда. Я удалил concatAdderss (поскольку он использует функцию Access), а также формулу IIF, чтобы определить, какую область использовать. Итоговые планы выполнения приведены ниже.

Фактические: https://drive.google.com/file/d/0B5o8fYhuyQ0ZODZCWHNIaS1KZ1k/view?usp=sharing Оценены: https://drive.google.com/file/d/0B5o8fYhuyQ0ZU0lnRUhvaXVkc1k/view?usp=sharing
Запрос занял 19 секунд для запуска непосредственно из SQL (от сервера облака)

Answer 1

места Вашего SQL на сервере как вид/прок, а затем вызвать, что вместо пытаясь устранить неполадки производительности в Access. Подумайте об использовании запроса «сквозной», который будет работать намного быстрее, чем связанные таблицы.