FOR XML SQL Server 2000 में पेश किया गया था।
SQL Server 2000 में MAX नहीं था डेटाटाइप या XML डेटा प्रकार। न ही FOR XML का उपयोग करना संभव था एक उप क्वेरी में।
लेख XML रिटर्न के लिए सर्वर साइड क्या करता है? बताते हैं
<ब्लॉकक्वॉट>
SQL Server 2000 में ... FOR XML ... क्वेरी प्रोसेसर और डेटा ट्रांसपोर्ट लेयर के बीच कोड की परत में कार्यान्वित किया गया था ... क्वेरी प्रोसेसर उसी तरह परिणाम उत्पन्न करता है जैसे बिनाFOR XML और फिर FOR XML कोड रोसेट को XML के रूप में प्रारूपित करता है। मैक्सिममएक्सएमएल प्रकाशन प्रदर्शन के लिए FOR XML परिणामी रोसेट के एक्सएमएल स्वरूपण को भाप देता है और सर्वर स्पेस में पूरे एक्सएमएल को बफर किए बिना सर्वर साइड टीडीएसकोड को सीधे छोटे हिस्सों में भेजता है। खंड का आकार 2033 यूसीएस -2 वर्ण है। इस प्रकार, 2033UCS-2 वर्णों से बड़ा XML क्लाइंट पक्ष को कई पंक्तियों में भेजा जाता है, जिनमें से प्रत्येक में XML का एक हिस्सा होता है। SQL सर्वर NTEXT प्रकार के एक कॉलम के साथ इस रोसेट के लिए एक पूर्वनिर्धारित कॉलमनाम का उपयोग करता है -“XML_F52E2B61-18A1-11d1-B105-00805F49916B "- UTF-16 एन्कोडिंग में खंडित XMLrowset को इंगित करने के लिए।
तो ऐसा प्रतीत होता है कि यह अभी भी शीर्ष स्तर FOR XML . के लिए उसी तरह लागू किया गया है बाद के संस्करणों में भी।
SQL सर्वर 2005 ने FOR XML का उपयोग करने की क्षमता पेश की उपश्रेणियों में (जिसका अर्थ है कि क्लाइंट को परिणामों को स्ट्रीम करते समय इन्हें अब इसके बाहर की परत के बजाय क्वेरी प्रोसेसर द्वारा नियंत्रित करने की आवश्यकता है)
वही लेख बताता है कि इन्हें NVARCHAR(MAX) . के रूप में टाइप किया जाएगा या XML type . की उपस्थिति पर निर्भर करता है या नहीं निर्देश।
साथ ही डेटाटाइप अंतर का मतलब अतिरिक्त SELECT . है यदि #tab . हो तो रैपर प्रदर्शन में भारी अंतर ला सकता है बड़ा है।
/*Can be streamed straight out to client without using server storage*/
SELECT col
FROM #tab
FOR XML AUTO
/*XML constructed in its entirety in tempdb first*/
SELECT(SELECT col
FROM #tab
FOR XML AUTO) AS wrapped_subquery
कॉल स्टैक के साथ-साथ निष्पादन योजनाओं में विभिन्न दृष्टिकोणों को देखना संभव है।
सीधे स्ट्रीम किया गया
sqllang.dll!CXMLExecContext::AddTagAndAttributes() + 0x5a9 bytes
sqllang.dll!CXMLExecContext::AddXMLRow() + 0x2b7 bytes
sqltses.dll!CEsExec::FastMoveEval() + 0x9c bytes
sqllang.dll!CXStmtQuery::ErsqExecuteQuery() + 0x280 bytes
sqllang.dll!CXStmtXMLSelect::WrapExecute() + 0x2d7 bytes
sqllang.dll!CXStmtXMLSelect::XretDoExecute() + 0x355 bytes
sqllang.dll!CXStmtXMLSelect::XretExecute() + 0x46 bytes
sqllang.dll!CMsqlExecContext::ExecuteStmts<1,1>() + 0x368 bytes
sqllang.dll!CMsqlExecContext::FExecute() + 0x6cb bytes
sqllang.dll!CSQLSource::Execute() + 0x3ee bytes
sqllang.dll!process_request() + 0x757 bytes
उप क्वेरी के साथ
sqllang.dll!CXMLExecContext::AddTagAndAttributes() + 0x5a9 bytes
sqllang.dll!CXMLExecContext::AddXMLRow() + 0x2b7 bytes
sqllang.dll!CForXmlSerialize::ProcessRow() + 0x19 bytes
sqllang.dll!CUDXR_Base::PushRow() + 0x30 bytes
sqlmin.dll!CQScanUdx::Open() + 0xd5 bytes
sqlmin.dll!CQueryScan::StartupQuery() + 0x170 bytes
sqllang.dll!CXStmtQuery::SetupQueryScanAndExpression() + 0x391 bytes
sqllang.dll!CXStmtQuery::InitForExecute() + 0x34 bytes
sqllang.dll!CXStmtQuery::ErsqExecuteQuery() + 0x217 bytes
sqllang.dll!CXStmtSelect::XretExecute() + 0xed bytes
sqllang.dll!CMsqlExecContext::ExecuteStmts<1,1>() + 0x368 bytes
sqllang.dll!CMsqlExecContext::FExecute() + 0x6cb bytes
sqllang.dll!CSQLSource::Execute() + 0x3ee bytes
sqllang.dll!process_request() + 0x757 bytes
दोनों एक ही अंतर्निहित एक्सएमएल कोड को कॉल करते हैं लेकिन "अनरैप्ड" संस्करण में योजना में कोई एक्सएमएल इटरेटर नहीं है, परिणाम CXStmtSelect से विधि कॉल को बदलकर प्राप्त किया जाता है। CXStmtXMLSelect . के साथ इसके बजाय (योजना में एक सादे पुराने चयन के बजाय एक XML चयन रूट नोड के रूप में प्रतिनिधित्व किया गया)।
SQL सर्वर 2016 CTP3 पर मुझे अभी भी ntext दिखाई दे रहा है शीर्ष स्तर के लिए FOR XML . हालांकि शीर्ष स्तर FOR JSON nvarchar(max) . के रूप में दिखाई देता है
कम से कम सीटीपी में JSON विशेष कॉलम नाम में अभी भी GUID F52E2B61-18A1-11d1-B105-00805F49916B शामिल है। इस तथ्य के बावजूद कि इसका मूल IXMLDocument इंटरफ़ेस है।
योजनाएँ काफी हद तक एक जैसी दिखती हैं, हालाँकि XML चयन को JSON चयन से बदल दिया गया है
BTW:बिल्ड पर Microsoft SQL Server 2014 - 12.0.4213.0 (X64) मुझे अस्थायी तालिकाओं और स्थायी तालिकाओं के बीच व्यवहार में कोई अंतर नहीं दिख रहा है। यह संभवत:भिन्न @@Version . के लिए है वातावरण के बीच आपका प्रश्न http://sqlfiddle.com/ (12.0.2000.8) और https://data.stackexchange.com/ (12.0.4213.0) का उपयोग करता है।
हो सकता है कि sys.dm_exec_describe_first_result_set में कोई बग ठीक किया गया हो दो 2014 के निर्माण के बीच।
2012 को मुझे 11.0.5343.0 (NULL के साथ) पर Shnugo के समान परिणाम मिलते हैं पहली तीन पंक्तियों में) लेकिन SP3 11.0.6020.0 स्थापित करने के बाद मुझे वही मिलता है जो प्रश्न में दिखाए गए आपके प्रारंभिक परिणाम हैं।
