800萬條記錄查詢性能

我有如下概述的查詢。鑑於zt_Arrival_Data表中有超過800萬條記錄，目前運行需要8分鐘以上，而zt_Tpl_Tuple_Stats_2故事僅包含9774條記錄，總共只有6946條獨特記錄。800萬條記錄查詢性能

以何種方式構建此查詢以提高性能？

SELECT distinct b.Tuple_ID 
    , LTRIM(RTRIM(a.ORIGIN_CITY)) + ', ' + LTRIM(RTRIM(a.ORIGIN_STATE)) AS Origin_TX 
    , LTRIM(RTRIM(a.DESTINATION_CITY)) + ', ' + LTRIM(RTRIM(a.DESTINATION_STATE)) AS Destination_TX 
    , LTRIM(RTRIM(a.ORIGIN_CITY)) + ' - ' + LTRIM(RTRIM(a.CUSTOMER_NAME)) AS Origin_Customer_TX 
    , LTRIM(RTRIM(a.ORIGIN_CITY)) + ' - ' + LTRIM(RTRIM(a.DESTINATION_CITY)) AS Origin_Destination_TX 
    , LTRIM(RTRIM(a.CUSTOMER_NAME)) AS Customer_Name 
    , LTRIM(RTRIM(a.CUSTOMER_NAME)) + ', ' + LTRIM(RTRIM(a.CUSTOMER_NO)) AS Customer_TX 
    , CASE 
      WHEN LTRIM(RTRIM(a.CUSTOMER_TYPE)) = 'C' THEN 'Customer' 
      WHEN LTRIM(RTRIM(a.CUSTOMER_TYPE)) = 'I' THEN 'Internal' 
      WHEN LTRIM(RTRIM(a.CUSTOMER_TYPE)) = 'S' THEN 'Shop' 
      WHEN LTRIM(RTRIM(a.CUSTOMER_TYPE)) = '' THEN 'zUnkown' 
      ELSE LTRIM(RTRIM(a.CUSTOMER_TYPE)) 
     END AS Customer_Type 
    , CASE 
      WHEN a.CARE_OF_NAME = '' THEN 'zUnknown' 
      ELSE a.CARE_OF_NAME 
     END AS Care_of_Name 
    , LTRIM(RTRIM(a.ORIGIN_CITY  )) AS Origin_City 
    , LTRIM(RTRIM(a.ORIGIN_STATE  )) AS Origin_State 
    , LTRIM(RTRIM(a.DESTINATION_CITY )) AS Destination_City 
    , LTRIM(RTRIM(a.DESTINATION_STATE )) AS Destination_State 
    , LTRIM(RTRIM(b.BusinessGroup_TX )) AS BusinessGroup_TX 
    , b.Fleet_TX AS Fleet_TX 
    , c.Leg_TX AS Leg_TX 
FROM   zt_Arrival_Data a 
INNER JOIN zt_Tpl_Tuple_Stats_2  b 
      ON LTRIM(RTRIM(a.ORIGIN_CITY)) + ', ' + LTRIM(RTRIM(a.ORIGIN_STATE)) = b.ORIGIN_TX 
      AND LTRIM(RTRIM(a.DESTINATION_CITY)) + ', ' + LTRIM(RTRIM(a.DESTINATION_STATE)) = b.DESTINATION_TX 
      AND a.CUSTOMER_NO = b.CUSTOMER_CD 
      AND a.BUSINESS_GROUP = b.BusinessGroup_TX 
      AND a.[FLEET_ID (GEN PLANT)] = b.Fleet_TX 
    JOIN zt_LegMap c ON c.Leg_CD = b.Leg_CD

來源

2016-03-22 Sauron

功能防止索引的使用，有一兩件事你可以做的是，從所有這些LTRIM級聯創建新列，至少在JOIN – Mihai

我檢查列看看你是否真的需要所有'TRIM'。我發現很多開發者只是把它們扔到了各處「因爲」。如果事實證明你的數據確實有各種前後空格（尾隨空格只應該用於'CHAR'列，而不是'VARCHAR'BTW），那麼修復數據而不是隨時編碼壞數據。 –

@Mihai：你需要做出答案，以便我們可以加入它。 – PaulProgrammer

這是遠遠更好地修剪數據條目，其中僅比做這樣的事情對在選擇一個大表發生一次數據。

這是一個特別糟糕的設計，你必須連接才能加入。當你做這些事情時，你失去了使用索引的能力。在SQL Server中，我會創建一個Ci可以加入的計算持久列，不確定是否有這樣的事情。但你應該調查這一點。

來源

2016-03-22 15:27:51 HLGEM

我繼承了很多這樣的代碼 – Sauron

不幸的是，你目前只能加速糟糕的設計。你需要修復你的數據模型並修復你的數據（同時確保它不會需要爲未來進行修剪）。這是需要重構才能正確工作，並且越快越好的原因。應該由除數據專家以外的任何人設計 – HLGEM

根據我的經驗，我已經瞭解到，當您需要格式化字段以便連接表格時，您應該格式化表格中具有較少行的列以匹配具有更多行的列，這些行必須保持不變。

一些想法開始：

FROM   zt_Arrival_Data a 
INNER JOIN zt_Tpl_Tuple_Stats_2  b 
     ON a.ORIGIN_CITY = <format the b table columns to match a.ORIGIN_CITY> 
     AND a.DESTINATION_STATE = <format the b table columns to match a.DESTINATION_STATE> 
     AND a.DESTINATION_CITY = <format the b table columns to match a.DESTINATION_CITY> 
     AND a.ORIGIN_STATE = <format the b table columns to match a.ORIGIN_STATE> 
     AND a.CUSTOMER_NO = b.CUSTOMER_CD 
     AND a.BUSINESS_GROUP = b.BusinessGroup_TX 
     AND a.[FLEET_ID (GEN PLANT)] = b.Fleet_TX

來源

2016-03-22 15:46:11 GigiSan

我希望我解釋一下自己，如果您需要更詳細的解釋，我將需要一些示例值： 'a.ORIGIN_CITY'， 'a.ORIGIN_STATE'， 'b.ORIGIN_TX'， 'a.DESTINATION_CITY'， 'a.DESTINATION_STATE'， 'b.DESTINATION_TX' 但我可能不會在周圍的一些分鐘，所以請原諒我，如果我不會很快回答。 – GigiSan

800萬條記錄查詢性能

回答

相關問題