Самый большой вид за всю историю!Как я могу уменьшить этого монстра ?? - PullRequest
Новая
       26

Самый большой вид за всю историю!Как я могу уменьшить этого монстра ??

0 голосов
/ 13 декабря 2010

Когда-то был вид с множеством соединений: 

CREATE VIEW [dbo].[V_BIGGEST_VIEW_EVER]
AS
SELECT {many many columns}
FROM (SELECT * FROM dbo.T_CUS_TSK_TASK WHERE is_deleted=0) T
  INNER JOIN dbo.V_CUS_GRP_GROUP G ON (T.group_id = G.group_id)
  INNER JOIN dbo.T_BKK_DISCOUNT_TYPE DT ON (DT.discount_type_id=T.discount_type_id)
  INNER JOIN dbo.T_BKK_CURRENCY DC ON (T.debit_currency_id=DC.currency_id)
  INNER JOIN dbo.T_BKK_CURRENCY PC ON (T.payback_currency_id=PC.currency_id)
  INNER JOIN dbo.T_BKK_CURRENCY FC ON (T.final_debit_currency_id=FC.currency_id)
  INNER JOIN dbo.T_GLOBAL_COUNTER D1C ON (D1C.company_id=T.company_id AND
    D1C.counter_name='PROFORMA_INVOICE_COUNTER')
  INNER JOIN dbo.T_GLOBAL_COUNTER D2C ON (D2C.company_id=T.company_id AND
    D2C.counter_name='TAX_INVOICE_COUNTER')
  INNER JOIN dbo.T_GLOBAL_COUNTER D3C ON (D3C.company_id=T.company_id AND
    D3C.counter_name='INVOICE_RECEIPT_COUNTER')
  INNER JOIN dbo.T_GLOBAL_COUNTER D4C ON (D4C.company_id=T.company_id AND
    D4C.counter_name='DELIVERY_NOTE_COUNTER')
  INNER JOIN dbo.T_GLOBAL_COUNTER D5C ON (D5C.company_id=T.company_id AND
    D5C.counter_name='BILL_OF_LADING_COUNTER')
  INNER JOIN dbo.T_GLOBAL_COUNTER D6C ON (D6C.company_id=T.company_id AND
    D6C.counter_name='CREDIT_INVOICE_COUNTER')
  LEFT JOIN dbo.V_SYS_BRANCH BR ON (T.branch_id = BR.branch_id)
  LEFT JOIN dbo.T_CUS_TSK_TASKS_ARRAY AR ON (T.array_id = AR.array_id)
  LEFT JOIN dbo.T_DRIVER D ON (T.driver_id = D.driver_id)
  LEFT JOIN dbo.T_VEHICLE V ON (T.vehicle_id = V.vehicle_id)
  LEFT JOIN dbo.T_STF_INVITER I ON (T.inviter_id = I.inviter_id)
  LEFT JOIN dbo.T_STF_SUBCONTRACTOR SC1 ON (SC1.subcontractor_id = D.subcontractor_id)
  LEFT JOIN dbo.T_STF_SUBCONTRACTOR SC2 ON (SC2.subcontractor_id = T.subcontractor_id)
  LEFT JOIN dbo.T_CUS_TSK_TASK_STATUS S ON (S.task_status_id=T.task_status_id)
  LEFT JOIN dbo.V_STF_SUB_LOCATION SL1 ON (SL1.sub_location_id=T.start_sub_location_id)
  LEFT JOIN dbo.V_STF_SUB_LOCATION SL2 ON (SL2.sub_location_id=T.end_sub_location_id)
  LEFT JOIN dbo.T_STF_CUSTOMER CU ON (CU.customer_id=T.customer_id)
  LEFT JOIN dbo.T_STF_CUSTOMER_SPLITTING_CODE SP ON (SP.splitting_id=T.splitting_id)
  LEFT JOIN dbo.V_CUS_TSK_CREDIT_FOR_TASK CR ON CR.task_id=T.task_id
  LEFT JOIN dbo.T_BKK_PROFORMA_INVOICE D1 ON (T.proforma_invoice_id=D1.proforma_invoice_id)
  LEFT JOIN dbo.T_BKK_TAX_INVOICE D2 ON (T.tax_invoice_id=D2.tax_invoice_id)
  LEFT JOIN dbo.T_BKK_INVOICE_RECEIPT D3 ON (T.invoice_receipt_id=D3.invoice_receipt_id)
  LEFT JOIN dbo.T_BKK_DELIVERY_NOTE D4 ON (T.delivery_note_id=D4.delivery_note_id)
  LEFT JOIN dbo.T_BKK_BILL_OF_LADING D5 ON (T.bill_of_lading_id=D5.bill_of_lading_id)
  LEFT JOIN dbo.V_CUS_TSK_CONTAINER CONTAINER1 ON (CONTAINER1.container_id=T.container1_id)
  LEFT JOIN dbo.V_CUS_TSK_CONTAINER CONTAINER2 ON (CONTAINER2.container_id=T.container2_id)
  LEFT JOIN dbo.V_STF_TRAILER TRAILER1 ON (TRAILER1.trailer_id=T.trailer1_id)
  LEFT JOIN dbo.V_STF_TRAILER TRAILER2 ON (TRAILER2.trailer_id=T.trailer2_id)
  LEFT JOIN dbo.T_STF_LUGGAGE_TYPE LUGGAGE_TYPE ON (LUGGAGE_TYPE.luggage_type_id=T.luggage_type_id)

Однажды пользователь запросил представление для запроса: 

SELECT {many many columns}
FROM V_BIGGEST_VIEW_EVER
WHERE {column1}=1 AND
      {column2}=2 AND
      .......
      {and so and so}
      .......
      {columnN}=N

И ленивый самый большой вид, который когда-либо работал, работал и после 5 минут (!!) и не менее возвращает результаты.

Эти таблицы имели первичные ключи и внешние ключи.

Как я могу сократить время выполнения запроса? Как я могу уменьшить это представление?

Я искал в Google, но не смог найти ничего, что могло бы помочь.

1 Ответ

3 голосов
/ 13 декабря 2010

Давайте на минуту посмотрим, что запрос соответствует действительному бизнес-требованию.

Тот факт, что представление большое, не означает, что он должен работать плохо. Производительность выбора из этого представления определяется главным образом макетом базовых таблиц . Даже с учетом того, что левые объединения более 20 таблиц поиска, SQL Server должен возвращать результат в миллисекундах при условии, что таблица T_CUS_TSK_TASK правильно проиндексирована для выполняемого запроса.

Вы должны подходить к этому так же, как к любой другой оптимизации запросов. Изучите основные факторы ввода-вывода (SET STATISTICS IO ON), изучите план запроса, посмотрите оценки мощности, проверьте правильность статистики, посмотрите на отсутствующие подсказки индекса запроса и подумайте, как можно соответствующим образом изменить схему таблиц. , Ваша отправная точка должна быть такой: Разработка индексов . Даже беглый взгляд на вашу (не представленную в посте) схему таблиц должен показать, что, скажем, deleted не крайний левый ключ кластеризованного индекса, тогда у вас наверняка есть проблема.

Ваш текущий подход к слепому взлому на запрос, основанный на тексте , совершенно непрофессиональный.

Сейчас, конечно, сложно , чтобы поверить, что этот запрос соответствует действительным требованиям бизнеса. Но, тем не менее, ваш взгляд на оптимизацию запросов и дизайн модели данных («У этих таблиц были первичные ключи и внешние ключи») примитивен, если использовать мягкий термин. Прочитайте о дизайне индексов, прочитайте о покрывающих индексах, купите книгу (например: Внутри Microsoft SQL Server 2005: настройка и оптимизация запросов ).

...