कम प्रदर्शन क्वेरी डेटाबेस चर

Question

मैं निम्नलिखित डीबी से शीर्ष 100 और 101 लाइनों और gettings elapsing बार, निकालने के लिए अगले प्रश्नों का उपयोग कर का उपयोग करते समय जो पूरी तरह से अलग (दूसरा क्वेरी ~ 8 पहले की तुलना में धीमी):

SELECT TOP (100) * 
FROM PhotoLike WHERE photoAccountId=@accountId AND accountId<>@accountId 
ORDER BY createDate DESC 
GO 

एसक्यूएल सर्वर निष्पादन टाइम्स: सीपीयू समय = 187 एमएस, विलुप्त समय = 202 एमएस।

SELECT TOP (101) * 
FROM PhotoLike WHERE photoAccountId=@accountId AND accountId<>@accountId 
ORDER BY createDate DESC 
GO 

एसक्यूएल सर्वर निष्पादन समय: CPU समय = 266 एमएस, बीता हुआ समय = 1644 एमएस। पहले दो मामलों की

निष्पादन योजना:

लेकिन अगर मैं @accoundId चर से छुटकारा पाने के, मैं निम्नलिखित मिल परिणाम है, जो लगभग बराबर होती है और तेजी से इस सवाल से पहले क्वेरी से अधिक से अधिक 2 बार।

SELECT TOP (100) * 
FROM PhotoLike WHERE photoAccountId=10 AND accountId<>10 
ORDER BY createDate DESC 
GO 

एसक्यूएल सर्वर निष्पादन समय: CPU समय = 358 एमएस, बीता हुआ समय = 90 एमएस।

SELECT TOP (101) * 
FROM PhotoLike WHERE photoAccountId=10 AND accountId<>10 
ORDER BY createDate DESC 
GO 

एसक्यूएल सर्वर निष्पादन समय: CPU समय = 452 एमएस, बीता हुआ समय = 93 एमएस।

निष्पादन दूसरा दो मामलों की योजना:

ऐसा क्यों होता है और मैं varibales साथ प्रदर्शन बेहतर बनाने?

अद्यतन

जोड़ा निष्पादन योजना है।

Answer 1

यहां कुछ चीजें चल रही हैं।

जब आप चर का उपयोग करते हैं तो SQL सर्वर सभी मानों को स्नीफ नहीं करता है, सिवाय इसके कि आप OPTION (RECOMPILE) भी जोड़ते हैं।

photoAccountId=@accountId से मेल खाने वाली पंक्तियों की संख्या अनुमान के मुकाबले अनुमान के मुकाबले बहुत छोटा है। (सूचकांक से बाहर आने वाली मोटी रेखा दूसरी योजना और समानांतर योजना का उपयोग करने का निर्णय देखें)।

इसके अलावा TOP 100/TOP 101TOP N के बीच cut off point तरह एक एल्गोरिथ्म है कि बस स्थान की आवश्यकता 100 पंक्तियों को सॉर्ट करने का उपयोग करने और यह एक पूर्ण तरह .. गलत पंक्ति संख्या अनुमान की संभावना का मतलब अपर्याप्त स्मृति पूर्ण प्रकार के लिए आवंटित है कर रही है और यह tempdb तक फैल रहा है।

बस चर के साथ क्वेरी में OPTION (RECOMPILE) जोड़ना संभवतः कुछ चीजों में सुधार करेगा, हालांकि ऐसा लगता है कि "तेज" योजना कई महत्वपूर्ण लुकअप कर रही है जो विभिन्न अनुक्रमणों से बचा जा सकता है।

Answer 2

मुझे आश्चर्य है कि यह पैरामीटर स्नीफिंग संबंधित हो सकता है। निम्नलिखित क्वेरी कितनी तेज़ी से जाती है?

DECLARE @accountIdParam int; 
SELECT @accountIdParam = @accountId; 

SELECT TOP (101) * 
FROM PhotoLike WHERE photoAccountId=@accountIdParam AND accountId<>@accountIdParam 
ORDER BY createDate DESC 
GO 

Answer 3

मैं कर सकता हूं, आपको अपनी तालिका के खाते आईडी फ़ील्ड के आधार पर क्लस्टर्ड इंडेक्स बनाना चाहिए।,

बनाएं अनन्य संकुल अनुक्रमणिका [IX_MyIndexName] पर [dbo] [PhotoLike] ( ACCOUNTID DESC, createDate DESC, photoAccountId DESC:।

आप एक असमानता का परीक्षण के रूप में, यह अधिक performant होना चाहिए )