2013-05-02 11 views
5

मेरे पास सामान्य रूप से बहुत सरल प्रश्न है और यह समझ में नहीं आता कि वास्तविक निष्पादन योजना मुझे "नेस्टेड लूप्स" नोड पर प्रारंभिक चयन के ठीक बाद "चेतावनी में शामिल हों" क्यों चेतावनी देता है।"कोई भविष्यवाणी नहीं करें" - क्यों?

मुझे लगता है कि क्वेरी बहुत आत्म-स्पष्टीकरणपूर्ण है: मेरे पास उपयोगकर्ता हैं और उनके पास फ़ीड्स के लिए उपयोगकर्ता सदस्यताएं हैं (एम: एन) - मैं एक फीड से सभी फीड इटम्स से पूछता हूं कि उपयोगकर्ता को सब्सक्राइब किया जाना चाहिए, इसलिए यह क्वेरी यह करती है बहुत अच्छी तरह से:

select fi.Title, fi.Content, fi.Published 
from [User] u 
inner join UserSubscription us on u.id = us.UserId 
inner join Feed f on f.id = us.FeedId 
inner join FeedItem fi on fi.FeedId = f.Id 
where u.EMailAddress = '[email protected]' 
and f.id = 3 
and fi.Inserted > getdate() - 30 

दिलचस्प हिस्सा वहाँ कोई चेतावनी के रूप में लंबे समय से मैं इस स्थिति को समाप्त छोड़ के रूप में है: जैसे ही मैं के बारे में चेतावनी निकाल देने के रूप में,

and f.id = 3 

लापता शामिल होने विधेय गायब हो जाता है । मैं यहां इस चेतावनी के कारण को समझ नहीं पा रहा हूं।

किसी भी मदद को समझने में इसकी सराहना की जाएगी!

धन्यवाद बी।

+5

qv http://dba.stackexchange.com/questions/34193/should-i-be-alarmed-by-this-no-join-predicate- चेतावनी और http://dba.stackexchange.com/questions/ 35082/क्या-बिल्कुल-करता-नहीं-join-predicate-mean-in-sql-server - संक्षेप में, यह * स्वचालित रूप से * एक बुरी चीज नहीं है – AakashM

+0

ठीक है जहां तक ​​मैं समझता हूं - मेरे मामले में SQL सर्वर अनुकूलित करेगा Feed.Id = 3 के लिए मेरी हालत के रूप में फ़ीड पर शामिल हों, असफल होने में? तो यही कारण है कि इस तालिका के लिए अब कोई भविष्यवाणी नहीं है? ठीक है, प्रदर्शन के अनुसार ... वास्तव में एक मुद्दा नहीं होना चाहिए। तर्कसंगत रूप से मुझे इसके बारे में सोचना होगा क्योंकि फ़ीड <-> उपयोगकर्ता सदस्यताएं किसी भी फ़ीड्स के लिए फ़िल्टर करने के लिए हैं, जहां उपयोगकर्ता वास्तव में सब्सक्राइब किया गया है क्योंकि ऐसा नहीं कहा जाता है कि उपयोगकर्ता ने इस उदाहरण में आईडी 3 के साथ फ़ीड की सदस्यता ली है। धन्यवाद! –

उत्तर

3

कारण आप फ़ीड मेज पर शामिल होने की आवश्यकता नहीं है क्योंकि यह है:

  1. f.id = us.FeedId = fi.FeedId
  2. f (फ़ीड) तालिका क्वेरी में/कहीं और आवश्यक नहीं किया जाता है (SELECT या

    select fi.Title, fi.Content, fi.Published 
    from [User] u 
    inner join UserSubscription us on u.id = us.UserId and us.FeedId = 3 
    inner join FeedItem fi on fi.FeedId = us.FeedId 
    where u.EMailAddress = '[email protected]' 
    and fi.Inserted > getdate() - 30 
    
    : WHERE)

यहाँ एक अधिक अनुकूलित क्वेरी है

इसे किसी विशेष फ़ीडआईडी में सीमित करके, आप अपना डेटासेट छोटा रखते हैं, और इसलिए तेज़ी से। अनुकूलक आपके लिए अपनी क्वेरी को बदल सकता है; मुझे यकीन नहीं है।

+2

मैं सहमत नहीं हूं कि आप उसमें शामिल हो सकते हैं। यदि फ़ीड में 3 की कोई आईडी नहीं है तो यह ओपी क्वेरी में नहीं होगी लेकिन यह आपके द्वारा पोस्ट की गई क्वेरी में होगी। – Paparazzi

+1

@ ब्लाम - जबकि सच है, मैं मूल प्रश्न और उसके तालिकाओं के नामों के आधार पर ओपी के सिस्टम की स्कीमा और बाधाओं के बारे में अपनी धारणाओं पर विश्वास करता हूं। मैं मानता हूं कि आपके द्वारा प्रस्तावित स्थिति का मौका है। –

+0

धन्यवाद @ coge.soft - पूर्ण ज्ञान बनाता है। ऐसा लगता है कि ऑप्टिमाइज़र इस जुड़ को हटा देगा और यह समझाएगा कि क्यों पॉप अप करने के लिए "कोई शामिल नहीं है" चेतावनी का कारण बनता है। वास्तव में दिलचस्प सामान। आपके लिए भी धन्यवाद, ब्लैम - लेकिन coge.soft सही है, मेरी स्कीमा की आवश्यकता है कि आईडी = 3 के साथ फ़ीड फ़ीड में मौजूद होना चाहिए जब उपयोगकर्ता प्रविष्टि में ऐसी प्रविष्टि मौजूद होती है। –

संबंधित मुद्दे