任何人都可以優化這條SQL語句嗎？

數據庫服務器是Microsoft SQL Server，但我沒有管理員訪問權限。所以，我不知道哪個版本，我不知道哪些索引存在。任何人都可以優化這條SQL語句嗎？

要訪問數據庫，我正在使用ADO。

這裏是SQL語句：

-- Get master objid and order_number and activity time 
SELECT A.objid, 
     A.order_number, 
     F.entry_time 
-- From these tables 
FROM dbo.table_master as A, 
     dbo.table_activity as F 
-- link of the tables 
WHERE F.objid = A.objid 
     -- Retrieve code = 1900 only 
     AND F.code = 1900 
     -- Which have info like this: 
     AND F.info LIKE '%to SUPPORT.' 
     -- And entry time between these times: 
     AND F.entry_time >= '2011-10-01 00:00:00' 
     AND F.entry_time <= '2011-12-05 23:59:59' 
-- We want the earliest entry (because there might be multiple code = 900 and info like) 
ORDER by F.entry_time

是否有可能進行優化呢？

謝謝

來源

2011-12-05 ewlung

它特別慢嗎？你能顯示查詢計劃嗎？另外，這個SQL的味道是什麼（SQL Server，MySQL等）？ – jadarnel27

您是否嘗試過從SSMS訪問數據庫？ –

@ jadarnel27：OP說這是SQLServer。 –

這裏有事情可以做不同的：

使用的

RIGHT(f.info, 11) = 'to SUPPORT.'代替F.info LIKE '%to SUPPORT.'
使用INNER JOIN作爲@xQbert建議的時間範圍，而不是組合
使用和>。

在我的測試中，唯一影響性能的因素是第一個選項。所有3個項目都會生成相同的執行計劃，但是，根據實際執行時間，RIGHT函數在我的測試中快了大約10倍。我正在使用STATISTICS TIME進行測試。

如果可能，我會嘗試訪問查看索引。正確編制索引表格會比RIGHT函數產生更大的差異。

來源

2011-12-05 14:33:51

謝謝。即使我從其他用戶讀取我的查詢很難優化，因爲沒有太多的信息（索引？），但我認爲你的RIGHT（）可能會有所幫助。 – ewlung

這是寫同一件事的不同方式;由於連接的性質和使用之間的關係，它可能產生更快的性能。它還限制了在％之前強制進行評估的連接標準，以便在評估％到SUPPORT時使用較小的子集。

SELECT A.objid, A.order_number, F.entry_time 
FROM dbo.table_master as A 
INNER JOIN dbo.table_activity as F 
    ON F.objid = A.objid 
    AND F.code = 1900 
    AND F.entry_time BETWEEN '2011-10-01 00:00:00' AND '2011-12-05 23:59:59' 
WHERE 
F.info LIKE '%to SUPPORT.' 
ORDER by F.entry_time

EDITED在第1條評論後。

來源

2011-12-05 14:17:46 xQbert

您所做的任何更改都不會影響性能。 –

這在性能上也有所提高。我改變了LIKE使用RIGHT（）。謝謝！ – ewlung

據我所知，您查詢的最糟糕的部分，也是部分不能容易地優化，是

AND F.info LIKE '%to SUPPORT.'

，因爲索引只從字符串的開頭匹配的工作，而不是從結束。

所以如果你想要更好的表現，你可能需要找到一些方法來解決這個問題。

（哦，才意識到這不是MySQL的這個答案將是MySQL的100％正確的，但我希望它爲最常見的數據庫引擎是正確的。）

來源

2011-12-05 14:20:49 Fox

這是所有指標的情況。如果您考慮將索引排序（將其作爲列表或樹並不重要），則最後一個字符只在所有前面的字符與另一個項匹配時才起作用。在本質上，這些項目的順序形成了該串的尾部的視角，實際上是隨機的。這意味着索引是無用的，並且整個表被掃描。 – MatBailie

但據我所知，你可以創建一個反轉的索引並查找反轉的字符串。這正是在這些情況下使用的。 – Flo

任何人都可以優化這條SQL語句嗎？

回答

相關問題