SQL सर्वर फ़ंक्शन जिन्हें रनटाइम स्थिरांक
केवल एक बार मूल्यांकन किया जाता है। GETDATE() ऐसा फ़ंक्शन है, और DATEADD(..., constant, GETDATE()) एक रनटाइम स्थिरांक भी है। वास्तविक फ़ंक्शन कॉल को क्वेरी के अंदर छोड़कर आप ऑप्टिमाइज़र को यह देखने देते हैं कि वास्तव में किस मूल्य का उपयोग किया जाएगा (जैसा कि एक चर मान सूंघने के विपरीत) और फिर यह अपने कार्डिनैलिटी अनुमानों को तदनुसार समायोजित कर सकता है, संभवतः एक बेहतर योजना के साथ आ रहा है।
इसे भी पढ़ें:खराब क्वेरी प्रदर्शन समस्या निवारण:कार्डिनैलिटी अनुमान के दौरान लगातार तह और अभिव्यक्ति मूल्यांकन ।
@मार्टिन स्मिथ
आप इस क्वेरी को चला सकते हैं:
set nocount on;
declare @known int;
select @known = count(*) from sysobjects;
declare @cnt int = @known;
while @cnt = @known
select @cnt = count(*) from sysobjects where getdate()=getdate()
select @cnt, @known;
मेरे मामले में 22 सेकंड के बाद यह सीमा के मामले में मारा और लूप निकल गया। महत्वपूर्ण बात यह है कि लूप @cnt . के साथ बाहर निकला है शून्य . कोई यह अपेक्षा करेगा कि यदि getdate() प्रति पंक्ति का मूल्यांकन किया जाता है तो हमें सही @ज्ञात गणना से अलग @cnt मिलेगा, लेकिन 0 नहीं। तथ्य यह है कि जब लूप मौजूद होता है तो @cnt शून्य होता है प्रत्येक getdate() दिखाता है एक बार मूल्यांकन किया गया था और फिर प्रत्येक पंक्ति के लिए समान स्थिर मान का उपयोग किया गया था जहां फ़िल्टरिंग (कोई मिलान नहीं)। मुझे पता है कि एक सकारात्मक उदाहरण एक प्रमेय साबित नहीं करता है, लेकिन मुझे लगता है कि मामला काफी निर्णायक है।
