🕰️ 😅 🙄 यह कैसे पता करें कि यह MySQL प्रश्नों को अनुकूलित करने के लायक है? 👏🏽 🙍🏼 👩‍👩‍👧‍👦

मुझसे अक्सर एक ही सवाल पूछा जाता है: मुझे ऐसे प्रश्न कैसे मिल सकते हैं जिन्हें अनुकूलित करने की आवश्यकता है। सब के बाद, कहते हैं, pt- क्वेरी-डाइजेस्ट रिपोर्ट को देखते हुए, हम सिस्टम पर एक बड़े लोड का कारण बनने वाले धीमी क्वेरी या प्रश्नों को आसानी से पा सकते हैं - लेकिन हम कैसे समझें कि इस क्वेरी को तेज़ी से बनाने का अवसर है या नहीं? इस सवाल का पूरा जवाब निश्चित रूप से एक व्यापक विश्लेषण की आवश्यकता होगी, क्योंकि प्रश्नों को अनुकूलित करने के कई तरीके हैं। हालांकि, एक बहुत ही उपयोगी मीट्रिक है जिसे आप लागू कर सकते हैं - क्वेरी द्वारा लौटाई गई पंक्तियों की संख्या और पूर्ण की गई पंक्तियों के बीच का संबंध।

मान लीजिए कि हमारे पास एक उदाहरण है:

# Time: 120911 17:09:44 # User@Host: root[root] @ localhost [] # Thread_id: 64914 Schema: sbtest Last_errno: 0 Killed: 0 # Query_time: 9.031233 Lock_time: 0.000086 Rows_sent: 0 Rows_examined: 10000000 Rows_affected: 0 Rows_read: 0 # Bytes_sent: 213 Tmp_tables: 0 Tmp_disk_tables: 0 Tmp_table_sizes: 0 # InnoDB_trx_id: 12F03 use sbtest; SET timestamp=1347397784; select * from sbtest where pad='abc';

इस मामले में क्वेरी ने 0 पंक्तियों को वापस कर दिया (क्योंकि हमारे पास कोई मिलान नहीं है), लेकिन इसके लिए उसे 10 मिलियन पंक्तियों से गुजरना पड़ा। कौन सा परिदृश्य बेहतर होगा? यदि अनुरोध उसी पंक्तियों के माध्यम से चला गया जो अंततः वापस आ जाएगी। इस स्थिति में, यदि मैं तालिका में अनुक्रमणिका की व्यवस्था करता हूं, तो मुझे धीमी क्वेरी लॉग में निम्न प्रविष्टि मिलेगी, जहां सभी धीमी गति से गिरते हैं:

 # Time: 120911 17:18:05 # User@Host: root[root] @ localhost [] # Thread_id: 65005 Schema: sbtest Last_errno: 0 Killed: 0 # Query_time: 0.000323 Lock_time: 0.000095 Rows_sent: 0 Rows_examined: 0 Rows_affected: 0 Rows_read: 0 # Bytes_sent: 213 Tmp_tables: 0 Tmp_disk_tables: 0 Tmp_table_sizes: 0 # InnoDB_trx_id: 12F14 SET timestamp=1347398285; select * from sbtest where pad='abc';

Rows_examined = 0 का एक मान, जो Rows_sent के साथ मेल खाता है, इसका मतलब है कि अनुरोध काफी अच्छी तरह से अनुकूलित है। ध्यान दें कि यदि आपने सोचा कि इस मामले में डेटाबेस तक पहुंच बिल्कुल नहीं है - तो आप गलत हैं। अनुक्रमित स्कैन किए जाते हैं, लेकिन चूंकि MySQL भाग द्वारा प्रसंस्करण के लिए केवल पाई गई पंक्तियों को पाया गया था और शीर्ष पर वापस लौटा गया था, Rows_examined का मूल्य शून्य के बराबर रहता है।
ऐसा लगता है कि सब कुछ बहुत सरल है, लेकिन यह बहुत जल्दबाजी में एक निष्कर्ष है। इस तरह का गणित केवल एग्रीगेट फंक्शन्स / ग्रुप के बिना प्रश्नों के साथ काम करेगा, इसके अलावा केवल उन प्रश्नों के लिए जो एक तालिका से गुजरते हैं। लेकिन उन प्रश्नों के बारे में क्या है जो एक से अधिक तालिका को प्रभावित करते हैं?

 # Time: 120911 17:25:22 # User@Host: root[root] @ localhost [] # Thread_id: 65098 Schema: sbtest Last_errno: 0 Killed: 0 # Query_time: 0.000234 Lock_time: 0.000063 Rows_sent: 1 Rows_examined: 1 Rows_affected: 0 Rows_read: 1 # Bytes_sent: 719 Tmp_tables: 0 Tmp_disk_tables: 0 Tmp_table_sizes: 0 # InnoDB_trx_id: 12F1D SET timestamp=1347398722; select * from sbtest a,sbtest b where a.id=5 and b.id=ak; mysql> explain select * from sbtest a,sbtest b where a.id=5 and b.id=ak; +----+-------------+-------+-------+---------------+---------+---------+-------+------+-------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | +----+-------------+-------+-------+---------------+---------+---------+-------+------+-------+ | 1 | SIMPLE | a | const | PRIMARY,k | PRIMARY | 4 | const | 1 | | | 1 | SIMPLE | b | const | PRIMARY | PRIMARY | 4 | const | 1 | | +----+-------------+-------+-------+---------------+---------+---------+-------+------+-------+ 2 rows in set (0.00 sec)

इस मामले में, हम वास्तव में दो तालिकाओं में शामिल हो जाते हैं, लेकिन क्योंकि तालिकाओं का उपयोग "स्थिर" करने के लिए सेट है, MySQL दो तालिकाओं तक पहुंच पर विचार नहीं करता है। "वास्तविक" पहुंच के मामले में, आउटपुट निम्नानुसार होगा:

 # Time: 120911 17:28:12 # User@Host: root[root] @ localhost [] # Thread_id: 65099 Schema: sbtest Last_errno: 0 Killed: 0 # Query_time: 0.000273 Lock_time: 0.000052 Rows_sent: 1 Rows_examined: 2 Rows_affected: 0 Rows_read: 1 # Bytes_sent: 719 Tmp_tables: 0 Tmp_disk_tables: 0 Tmp_table_sizes: 0 # InnoDB_trx_id: 12F23 SET timestamp=1347398892; select * from sbtest a,sbtest b where ak=2 and b.id=a.id; +----+-------------+-------+--------+---------------+---------+---------+-------------+------+-------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | +----+-------------+-------+--------+---------------+---------+---------+-------------+------+-------+ | 1 | SIMPLE | a | ref | PRIMARY,k | k | 4 | const | 1 | | | 1 | SIMPLE | b | eq_ref | PRIMARY | PRIMARY | 4 | sbtest.a.id | 1 | | +----+-------------+-------+--------+---------------+---------+---------+-------------+------+-------+ 2 rows in set (0.00 sec)

इस मामले में, हमारे पास पंक्तियों के प्रत्येक सेट के लिए 2 विश्लेषण की गई पंक्तियाँ हैं, जो अपेक्षित है, क्योंकि हमारे पास इस क्वेरी में 2 (तार्किक) तालिकाओं का उपयोग किया गया है। अनुरोध में समूह होने पर भी यह नियम काम नहीं करेगा:

 # Time: 120911 17:31:48 # User@Host: root[root] @ localhost [] # Thread_id: 65144 Schema: sbtest Last_errno: 0 Killed: 0 # Query_time: 5.391612 Lock_time: 0.000121 Rows_sent: 2 Rows_examined: 10000000 Rows_affected: 0 Rows_read: 2 # Bytes_sent: 75 Tmp_tables: 0 Tmp_disk_tables: 0 Tmp_table_sizes: 0 # InnoDB_trx_id: 12F24 SET timestamp=1347399108; select count(*) from sbtest group by k;

यह क्वेरी केवल 2 पंक्तियों को लौटाएगी, हालाँकि यह 10 मिलियन से गुजरेगी, और हम इस क्वेरी को सरल तरीके से अनुकूलित नहीं कर सकते हैं, क्योंकि परिणामों को समूहीकृत करने के लिए सभी पंक्तियों से गुजरना वास्तव में आवश्यक है।
इस मामले में, आप अनुरोध द्वारा समूह को हटाने और कार्यों को एकत्र करने के बारे में सोच सकते हैं। फिर अनुरोध “select * from sbtest” में बदल जाएगा, जो सभी 10 मिलियन पंक्तियों को वापस कर देगा और इसलिए, सरल अनुकूलन के तरीके नहीं होंगे।
यह विधि आपको एक स्पष्ट हां या कोई जवाब देने के लिए नहीं बनाई गई थी, लेकिन यह बहुत मदद कर सकती है कि आप अंत में किस प्रकार का अनुकूलन प्राप्त कर सकते हैं। मान लीजिए कि मेरे पास एक क्वेरी है जो 1000 पंक्तियों के सूचकांक का उपयोग करता है और 10 रिटर्न देता है ... मैं अभी भी उन पंक्तियों की संख्या को 100 गुना कम करने में सक्षम हो सकता हूं - उदाहरण के लिए, संयुक्त अनुक्रमित जोड़कर।

तो, संक्षेप में - आप जल्दी से कैसे पता लगा सकते हैं कि यह किसी क्वेरी को अनुकूलित करने के लायक है या नहीं?
- समूह, अलग और समग्र कार्यों (ए) को हटाने के बाद क्वेरी कितनी पंक्तियों को वापस देखती है
- बी (बी) में तालिकाओं की संख्या से विभाजित की गई पंक्तियों की संख्या लें
- यदि B A से कम या बराबर है, तो आपका अनुरोध "पूर्ण" है
- यदि बी / ए 10 या अधिक है। तब यह अनुरोध अनुकूलन के लिए सबसे योग्य उम्मीदवारों में से एक है।

यह एक सरल विधि है और इसे सुरक्षित रूप से पीटी-क्वेरी-डाइजेस्ट के साथ उपयोग किया जा सकता है, क्योंकि बाद की रिपोर्टें न केवल औसत मूल्य, बल्कि बाध्य मान भी हैं।

मूल लेख: यहाँ ।

यह कैसे पता करें कि यह MySQL प्रश्नों को अनुकूलित करने के लायक है?

More articles: