SQL select 運行不出結果
例子不好舉，只能先貼下具體問題。
下邊是查詢出問題的語句。查詢后 會卡在某條數據不動了。
單獨查詢 i 執行沒有問題
單獨執行p 也沒有問題
歡迎各位大神來遠程，可以直接加Q 915572879
沒法執行完，卡在最下邊的那條數據后，就不動了、
i 加上nolock也是不行 還是一樣的問題。
i查出來是33724行，p是26969行。
如果一個表查詢了放臨時表， 再連接查詢， 最終的結果集有多少行？
做臨時表連接查詢最終結果33724行。
直接執行count(1) 無法執行成功。
i是一個視圖，嵌套比較多。
加distinct 解決問題，希望大神留個原理。
下邊是查詢出問題的語句。查詢后 會卡在某條數據不動了。
SELECT i.ClientId --,p.*
FROM dbo.V_WMS_Inventory AS i
inner JOIN
(
SELECT prod.Id
FROM dbo.T_WMS_Product AS prod with(nolock) inner JOIN
dbo.T_CMN_Client AS c with(nolock) ON prod.ClientID = c.Id LEFT OUTER JOIN
dbo.T_WMS_Product_Category AS pc with(nolock) ON pc.Category = prod.ProdCategory
)p
ON i.ProductId = p.Id
單獨查詢 i 執行沒有問題
單獨執行p 也沒有問題
歡迎各位大神來遠程，可以直接加Q 915572879
18 个解决方案
#1
是不是計算量很大，等查詢完后，看一下執行計划
#2
沒法執行完，卡在最下邊的那條數據后，就不動了、
#3
上邊貼的SQL p 中 有with(nolock)，有沒有這個都會卡在一條數據上 不動。另外說下，數據庫只執行這一個select。如果 將其中一個表查詢結果放入臨時表 然后做連接查詢就沒有問題。坐等各位大神。。
#4
i 和 p 查出來各有多少條？
#5
--i 后加 with(nolock) 試試
SELECT i.ClientId --,p.*
FROM dbo.V_WMS_Inventory AS i WITH(NOLOCK)
INNER JOIN
(
SELECT prod.Id
FROM dbo.T_WMS_Product AS prod with(nolock) inner JOIN
dbo.T_CMN_Client AS c with(nolock) ON prod.ClientID = c.Id LEFT OUTER JOIN
dbo.T_WMS_Product_Category AS pc with(nolock) ON pc.Category = prod.ProdCategory
) AS p
ON i.ProductId = p.Id
#6
i 加上nolock也是不行 還是一樣的問題。
i查出來是33724行，p是26969行。
#7
如果一個表查詢了放臨時表， 再連接查詢， 最終的結果集有多少行？
#8
先試試 select count(*) 是否能出來，能的話數據是多少
#9
做臨時表連接查詢最終結果33724行。
#10
直接執行count(1) 無法執行成功。
#11
i 中所有ProductId 都可以在 p的id 結果集中找到。
#t 為p 的臨時表
#t 為p 的臨時表
#12
你的 I 是視圖吧？ 看名稱是 V 打頭的，如果是的話，建議你看執行計划，猜測是一個復雜的執行計划，並不是你給出的語句這么簡單的一個查詢
#13
你可以嘗試把你的子查詢加個 DISTINCT 試試
SELECT DISTINCT prod.id
SELECT DISTINCT prod.id
#14
i是一個視圖，嵌套比較多。
#15
加distinct 解決問題，希望大神留個原理。
#16
簡單地說，就是子查詢是做為一個整體參與外層查詢（相當於子查核鐵數據會先查出緩存到臨時表），還是會被查詢優化器分解和外層查詢配合（不是單純的執行子查詢，是子查詢的某些表可能先與外層查詢 JOIN)
LEFT JOIN 和 DISTINCT 的方式基本上會讓查詢優化器無法進行上述第2種情況的處理
而上述的第2種情況，在查詢復雜或表中統計信息不准確，或數據分布不均等的情況下容易整出不佳的執行計划，所以一真強調要看看執行計划
關於執行計划的分析，可以看我在另一個地方的回復 https://social.msdn.microsoft.com/Forums/zh-CN/626527ca-4d3e-4339-91d3-2cc88d913f85?forum=sqlserverzhchs
LEFT JOIN 和 DISTINCT 的方式基本上會讓查詢優化器無法進行上述第2種情況的處理
而上述的第2種情況，在查詢復雜或表中統計信息不准確，或數據分布不均等的情況下容易整出不佳的執行計划，所以一真強調要看看執行計划
關於執行計划的分析，可以看我在另一個地方的回復 https://social.msdn.microsoft.com/Forums/zh-CN/626527ca-4d3e-4339-91d3-2cc88d913f85?forum=sqlserverzhchs
#17
感謝各位的回復，結貼了。
具體原因雖然不清楚，但算是有了個方向。
具體原因雖然不清楚，但算是有了個方向。
#18
注意！
本站转载的文章为个人学习借鉴使用，本站对版权不负任何法律责任。如果侵犯了您的隐私权益，请联系我们删除。