有2個表emailinfo（id，email）和keywordinfo（id，關鍵字）。 emailinfo包含80,000行，keywordinfo包含2000行。LIKE使用子查詢返回多行
我想要emailinfo表中沒有包含來自keywordinfo表的關鍵字的電子郵件。
我想不喜歡在多行
我一直都關鍵字keywordinfo表
現在我已經獲取所有從emailinfo表，該表不包含從keywordinfo表的所有關鍵字的郵件狀態。
我想查詢像下面，
select email
from emailinfo
where email not like % (select keyword from keywordinfo)
我曾嘗試下面的查詢
SELECT email
FROM emailinfo
join keywordinfo on email like '%' + keyword +'%'**
，但它不是給我正確的結果，是非常緩慢的。
第二個查詢的輕微變化怎麼樣...？
SELECT Email
FROM EmailInfo
LEFT JOIN KeywordInfo ON Email LIKE '%' + Keyword + '%'
WHERE KeywordInfo.ID IS NULL
示例數據：
CREATE TABLE #EmailInfo (ID INT, Email VARCHAR(50))
INSERT INTO #EmailInfo (ID, Email) VALUES (1, '[email protected]')
INSERT INTO #EmailInfo (ID, Email) VALUES (2, '[email protected]')
INSERT INTO #EmailInfo (ID, Email) VALUES (3, '[email protected]')
INSERT INTO #EmailInfo (ID, Email) VALUES (4, '[email protected]')
INSERT INTO #EmailInfo (ID, Email) VALUES (5, '[email protected]')
INSERT INTO #EmailInfo (ID, Email) VALUES (6, '[email protected]')
CREATE TABLE #KeywordInfo (ID INT, Keyword VARCHAR(50))
INSERT INTO #KeywordInfo (ID, Keyword) VALUES (1, 'sample')
INSERT INTO #KeywordInfo (ID, Keyword) VALUES (2, 'test')
SELECT Email
FROM #EmailInfo EmailInfo
LEFT JOIN #KeywordInfo KeywordInfo ON Email LIKE '%' + Keyword + '%'
WHERE KeywordInfo.ID IS NULL
DROP TABLE #EmailInfo
DROP TABLE #KeywordInfo
不鎖定不是一個好主意，它會讀取未提交的記錄。該查詢將返回重複的記錄。 –
@Romil，我想這是真的，一個電子郵件地址可能會匹配多個關鍵字，但我們顯示的是不匹配的記錄...所以它不應該需要一個GROUP BY或DISTINCT，從什麼我可以告訴... –
以下查詢將返回未在keywordinfo表中定義任何關鍵字的emailinfo表中的所有記錄。
建議在emailinfo.email字段上使用索引以使查詢執行更快。
SELECT * FROM emailinfo
where not exists (Select 1 from
keywordinfo where emailinfo.email like '%' + keywordinfo.keyword +'%')
'SELECT 1'優於'SELECT TOP 1' –
TOP的使用在這裏什麼也不做（除了使查詢不可移植到沒有TOP操作符的SQL方言）。查詢優化器知道相關子查詢中的任何單個行都使該行的NOT EXISTS爲false。 SELECT *可能是最好的 - 沒有解析的表達式，而在NOT EXISTS中，它不會擴展到列的列表。 –
前1是由編寫我的答案而不知道嵌套查詢與存在子句的「@Photon致命錯誤」編寫的。 –
另一種製劑消除了這樣的：
Select
From emailinfo ie
Where not exists (select *
From ki
Where charindex(ki.keyword, ie.email) > 0)
我道歉的格式，我在移動設備上。
我也建議你改變你的表結構，使每個關鍵字在一個單獨的行。那麼你將不需要像運營商一樣。
請告訴我如何改變我的桌子結構。因爲我嘗試了以上所有解決方案，但需要花費相同的時間。 –
而不是試圖想出了使用LIKE的場景中，你有沒有使用全文索引考慮？
皮納爾戴夫上有一個相當不錯的介紹，可以幫助您開始：http://blog.sqlauthority.com/2008/09/05/sql-server-creating-full-text-catalog-and-index/
你的第二個查詢會給你確實是會包含關鍵字的郵件。對於那些不使用Romil建議的NOT EXISTS查詢。對內部子字符串的任何查詢可能會很慢，因爲沒有索引是有用的。如果某些關鍵字比其他關鍵字更普遍，那麼可能有一些方法可以哄騙那些首先被檢查的關鍵字，但是您必須進行一些設計更改。 –
感謝您回覆me.please告訴我一些有效的方法來處理這種情況，因爲我嘗試了所有的答案，仍然需要2分鐘來運行我的查詢。 –
@UdaySatardekar，緩慢的速度可能是由於數據庫設計和您正在使用的數據量。 –