如何加快這個T-SQL查詢

表的人（姓名，出生日期，身份證等）
表NewRecords（姓名，出生日期，SSN）
我想寫的是確定哪些NewRecords查詢不以任何方式匹配任何人（這是一個更新查詢，在NewRecords表中設置了一個標誌）。如何加快這個T-SQL查詢

具體來說，我想找到NewRecords爲它的第一個名字，姓氏和SSN之間的Levenshtein距離是大於2的所有記錄在人。（即該人具有與人中所有人不同的第一個，最後一個和ssn，因此可能不匹配）。

我添加了一個用戶定義的Levensthein函數Levenshtein distance in T-SQL並且已經添加了一個優化，爲最大允許距離添加了一個額外的參數。（如果計算的levenstein爬升到允許的最大值以上，該函數會提前退出）。但由於表格很大，查詢仍然需要很長的時間。

我能做些什麼來加快速度？我如何開始考慮優化和性能？在什麼時候我需要開始挖掘SQL Server的內部？

update NewRecords 
set notmatchflag=true 
from 
newRecords elr 
inner join People pro 
on 
dbo.Levenshtein_withThreshold(elr.last,pro.last,2)>2 and 
dbo.Levenshtein_withThreshold(elr.first,pro.first,2)>2 and 
elr.ssn is null and 
elr.dob<>pro.dob

來源

2013-04-29 bernie2436

執行計劃？ – Kermit 2013-04-29 13:49:47

你有沒有試過C＃CLR存儲過程？這些字符串操作比SQL用戶定義的函數要好得多。 – Andomar 2013-04-29 13:53:12

Scalar UDF在SQL Server上的性能令人失望。再加上搜索子句中的大部分函數和表達式都會阻止它能夠使用該部分搜索的索引。如果您向我們展示您的UDf的代碼，我們可能會將其轉化爲可以更好地優化的東西。 – RBarryYoung 2013-04-29 13:57:45

由於不確切地知道表結構和數據類型，我不是100％確定這可以工作，而是無論如何都要堅持下去！

我會在測試它時首先檢查SQL執行計劃，通常會有一些部分花費最多的時間。從那裏你應該能夠衡量哪裏/哪些指標會有所幫助。

雖然我的直覺是你的功能被稱爲很多東西的外觀，但希望執行計劃將確定是否是這種情況。如果是這樣，那麼CLR存儲過程可能就是要走的路。

來源

2013-04-29 13:53:54 XN16

你的查詢似乎沒有什麼問題（除了事實上，你想找到所有可能的不同值的組合，在大多數情況下會給出很多結果:)）。

無論如何，問題在於你的Levenstein函數 - 我認爲它們是用T-SQL編寫的。即使你優化了它們，它們仍然很脆弱。你真的應該把它們編譯成CLR（你發佈的鏈接已經包含了一個例子） - 這將會快上一個數量級。

另一個想法，我會嘗試與你有什麼，是以某種方式減少萊文斯坦比較的數量。也許找其他條件，或反向查詢：尋找所有匹配的記錄，然後選擇還剩下些什麼（它可以使您介紹這些附加條件

但萊文施泰因編譯爲CLR是您最好的選擇

來源

2013-04-29 13:54:46

有關。一個跳過的值是真的，所以如果你再次運行它，那麼它將不會處理這些
這個距離是昂貴的 - 嘗試消除那些沒有機會第一
如果長度相差超過2那麼我認爲你不會有距離< = 2。

update NewRecords 
set notmatchflag=true 
from newRecords elr 
inner join People pro 
    on notmatchflag = false 
and elr.ssn is null 
and elr.dob <> ro.dob 
and dbo.Levenshtein_withThreshold(elr.last, pro.last,2) > 2 
and dbo.Levenshtein_withThreshold(elr.first,pro.first,2) > 2

來源

2013-04-29 15:15:26 Paparazzi

如何加快這個T-SQL查詢

回答

相關問題