कुल तार्किक रीड और कुल भौतिक रीड्स को देखने के लिए आप इन दो प्रश्नों में से एक का उपयोग कर सकते हैं।
SELECT DB_NAME(st.dbid) Db,
OBJECT_NAME(st.objectid, st.dbid) Prc,
qs.execution_count,
qs.total_logical_reads,
qs.total_physical_reads,
qs.statement_start_offset,
qs.statement_end_offset,
st.text
FROM sys.dm_exec_query_stats qs
CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) st;
SELECT DB_NAME(database_id) Db,
OBJECT_NAME(object_id, database_id) Prc,
execution_count,
total_logical_reads,
total_physical_reads
FROM sys.dm_exec_procedure_stats ps;
पहला एक बयान द्वारा इसे तोड़ता है, दूसरा पूरी प्रक्रिया में गिना जाता है।
भौतिक रीड्स डिस्क के खिलाफ पढ़े जाते हैं, तार्किक रीड मेमोरी के खिलाफ होते हैं। आप इसका उपयोग यह पता लगाने के लिए कर सकते हैं कि आपके सिस्टम में कौन सी प्रक्रियाएं या कथन सबसे महंगे हैं और उन को ट्यून करने का प्रयास करें।
ध्यान रखें, जबकि तार्किक रीड्स काफी सस्ते हैं कि भौतिक रीड्स, वे अभी भी महंगे हैं, इसलिए उनमें से संख्या को कम करना (उदाहरण के लिए एक उपयुक्त इंडेक्स जोड़कर) आपके प्रश्नों को बहुत तेजी से चला सकता है।
उपरोक्त DMV में बहुत सारे अतिरिक्त कॉलम हैं जो आपको दिलचस्प भी लग सकते हैं।
तार्किक रीडर्स को कम करने के लिए एक इंडेक्स कैसे मदद करता है?
SQL सर्वर में सभी डेटा को ब्लॉक, 8KB आकार में व्यवस्थित किया जाता है। इन ब्लॉकों को "पृष्ठ" कहा जाता है।
हर तालिका में "मेटा" पृष्ठ होते हैं, जिसमें तालिका के स्ट्रिंग के साथ-साथ पाटा पृष्ठों के बारे में जानकारी होती है। यदि कोई इंडेक्स मौजूद नहीं है और आप एक क्वेरी चलाते हैं जैसे SELECT * FROM tbl WHERE Id = 7SQL सर्वर को पूरी तालिका में इस या इन पंक्तियों की तलाश में जाना पड़ता है। तो यह एक समय में एक पृष्ठ में पढ़ता है, जो WHEREखंड को फिट करने वाली पंक्तियों को निर्धारित करने के लिए प्रत्येक पृष्ठ में सभी पंक्तियों के माध्यम से लूप करता है। इसलिए यदि तालिका में 1,000,000 पृष्ठों को संग्रहीत करने की आवश्यकता है, तो यह क्वेरी निष्पादित करने के लिए 1,000,000 तार्किक रीड्स लेगी।
यदि आपके पास एक इंडेक्स है, तो SQL सर्वर पन्नों के भीतर तार्किक रूप से डेटा को सॉर्ट करता है और पृष्ठों के बीच एक लिंक्ड सूची स्थापित करता है। यह ORDER BYएक महंगे सॉर्ट ऑपरेशन के बिना निष्पादित किए जाने वाले प्रश्नों को चलाने की अनुमति देता है । लेकिन महत्वपूर्ण बात यह है कि सॉर्टिंग, SQL सर्वर तालिका में B + ट्री जोड़ता है । एक बी + ट्री एक पुस्तक में सूचकांक की तुलना में एक संरचना है, जहां एक विशिष्ट कीवर्ड की तलाश मुझे उस पृष्ठ पर सीधे कूदने की अनुमति देती है जिसमें कीवर्ड होता है। विशिष्ट पुस्तक में केवल एक सूचकांक स्तर होता है जबकि एक B + ट्री में कई हो सकते हैं। बस एक बड़ी पुस्तक के बारे में सोचें, जहां सूचकांक खुद कई पृष्ठों लंबा हो। इस तरह के मामले में यह समझ में आता है कि एडिशनल इंडेक्स लेयर जो हमें wich पेज पर बताती है उसके साथ शुरू होने वाले इंडेक्स शब्द Sपाए जाते हैं।
B + पेड़ों को संपत्ति प्रदान करते समय यथासंभव कुछ स्तरों के लिए अनुकूलित किया जाता है जो सूचकांक में किसी भी रिकॉर्ड को सूचकांक स्तर के एक पृष्ठ को पढ़कर पाया जा सकता है। इसलिए WHERE Id = 7जब आप द्वारा अनुक्रमित अनुक्रमित हो तो उपरोक्त क्वेरी मान लें Id। मान लीजिए कि सूचकांक के 5 स्तर हैं। अब, इस क्वेरी से मेल खाने वाले सभी रिकॉर्ड्स को खोजने के लिए मुझे प्रति इंडेक्स स्तर पर एक पेज पढ़ना होगा (यह 5 पेज है)। इसे "इंडेक्स सीक" कहा जाता है। यदि कई रिकॉर्ड हैं जो बिल को फिट करते हैं तो मुझे उन सभी को पुनः प्राप्त करने के लिए कुछ समय के लिए सॉर्ट किए गए सूचकांक का पालन करना पड़ सकता है। लेकिन मान लेते हैं कि केवल एक ही रिकॉर्ड है।
इसलिए, उस इंडेक्स के बिना उस क्वेरी को 1,000,000 रीड की आवश्यकता होती है, इंड्स के साथ उसे 5 रीड की आवश्यकता होती है। भले ही एक तार्किक रीड एक इन-मेमोरी ऑपरेशन हो, लेकिन इसमें पर्याप्त लागत होती है - वास्तव में यह ऊपर की तरह एक तुच्छ क्वेरी में सबसे महंगा ऑपरेशन है। इसलिए 200,000 के कारक द्वारा आवश्यक तार्किक रीड की मात्रा को कम करने से आपके क्वेरी को समान कारक द्वारा गति मिलेगी।
तो, एक लॉजिकल रीड टेबल टेबल के बराबर नहीं है, लेकिन टेबल स्कैन इंडेक्स की तलाश में पूरी तरह से अधिक तार्किक रीड का कारण बनता है।
