धीमी क्वेरी, अक्षम क्वेरी, या लंबे समय तक चलने वाली क्वेरी ऐसी समस्याएं हैं जो नियमित रूप से DBA को परेशान करती हैं। वे हमेशा सर्वव्यापी होते हैं, फिर भी डेटाबेस के प्रबंधन के लिए जिम्मेदार किसी भी व्यक्ति के लिए जीवन का एक अनिवार्य हिस्सा हैं।
खराब डेटाबेस डिज़ाइन क्वेरी की दक्षता और उसके प्रदर्शन को प्रभावित कर सकता है। ज्ञान की कमी या फ़ंक्शन कॉल, संग्रहीत कार्यविधियों, या रूटीन का अनुचित उपयोग भी डेटाबेस के प्रदर्शन में गिरावट का कारण बन सकता है और यहां तक कि पूरे MySQL डेटाबेस क्लस्टर को भी नुकसान पहुंचा सकता है।
मास्टर-स्लेव प्रतिकृति के लिए, इन समस्याओं का एक बहुत ही सामान्य कारण प्राथमिक या द्वितीयक अनुक्रमणिका की कमी वाली तालिकाएं हैं। यह दास अंतराल का कारण बनता है जो बहुत लंबे समय तक (एक बदतर स्थिति में) रह सकता है।
इस दो-भाग श्रृंखला ब्लॉग में, हम आपको बेहतर दक्षता और प्रदर्शन के लिए MySQL में अपने डेटाबेस प्रश्नों को अधिकतम करने के तरीके पर एक पुनश्चर्या पाठ्यक्रम देंगे।
अपनी तालिका में हमेशा एक अद्वितीय अनुक्रमणिका जोड़ें
ऐसी तालिकाएँ जिनमें प्राथमिक या अद्वितीय कुंजियाँ नहीं होती हैं, डेटा के बड़े होने पर आमतौर पर बड़ी समस्याएँ पैदा होती हैं। जब ऐसा होता है तो एक साधारण डेटा संशोधन डेटाबेस को रोक सकता है। उचित सूचकांकों की कमी और एक विशेष तालिका में एक अद्यतन या हटाएं कथन लागू किया गया है, एक पूर्ण तालिका स्कैन को MySQL द्वारा क्वेरी योजना के रूप में चुना जाएगा। यह पढ़ने और लिखने के लिए उच्च डिस्क I/O का कारण बन सकता है और आपके डेटाबेस के प्रदर्शन को खराब कर सकता है। नीचे एक उदाहरण देखें:
root[test]> show create table sbtest2\G
*************************** 1. row ***************************
Table: sbtest2
Create Table: CREATE TABLE `sbtest2` (
`id` int(10) unsigned NOT NULL,
`k` int(10) unsigned NOT NULL DEFAULT '0',
`c` char(120) NOT NULL DEFAULT '',
`pad` char(60) NOT NULL DEFAULT ''
) ENGINE=InnoDB DEFAULT CHARSET=latin1
1 row in set (0.00 sec)
root[test]> explain extended update sbtest2 set k=52, pad="xx234xh1jdkHdj234" where id=57;
+----+-------------+---------+------------+------+---------------+------+---------+------+---------+----------+-------------+
| id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra |
+----+-------------+---------+------------+------+---------------+------+---------+------+---------+----------+-------------+
| 1 | UPDATE | sbtest2 | NULL | ALL | NULL | NULL | NULL | NULL | 1923216 | 100.00 | Using where |
+----+-------------+---------+------------+------+---------------+------+---------+------+---------+----------+-------------+
1 row in set, 1 warning (0.06 sec)जबकि प्राथमिक कुंजी वाली तालिका में एक बहुत अच्छी क्वेरी योजना होती है,
root[test]> show create table sbtest3\G
*************************** 1. row ***************************
Table: sbtest3
Create Table: CREATE TABLE `sbtest3` (
`id` int(10) unsigned NOT NULL AUTO_INCREMENT,
`k` int(10) unsigned NOT NULL DEFAULT '0',
`c` char(120) NOT NULL DEFAULT '',
`pad` char(60) NOT NULL DEFAULT '',
PRIMARY KEY (`id`),
KEY `k` (`k`)
) ENGINE=InnoDB AUTO_INCREMENT=2097121 DEFAULT CHARSET=latin1
1 row in set (0.00 sec)
root[test]> explain extended update sbtest3 set k=52, pad="xx234xh1jdkHdj234" where id=57;
+----+-------------+---------+------------+-------+---------------+---------+---------+-------+------+----------+-------------+
| id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra |
+----+-------------+---------+------------+-------+---------------+---------+---------+-------+------+----------+-------------+
| 1 | UPDATE | sbtest3 | NULL | range | PRIMARY | PRIMARY | 4 | const | 1 | 100.00 | Using where |
+----+-------------+---------+------------+-------+---------------+---------+---------+-------+------+----------+-------------+
1 row in set, 1 warning (0.00 sec)प्राथमिक या अद्वितीय कुंजियाँ तालिका संरचना के लिए महत्वपूर्ण घटक प्रदान करती हैं क्योंकि यह विशेष रूप से तालिका पर रखरखाव करते समय बहुत महत्वपूर्ण है। उदाहरण के लिए, पेरकोना टूलकिट (जैसे पीटी-ऑनलाइन-स्कीमा-चेंज या पीटी-टेबल-सिंक) के टूल का उपयोग करने से अनुशंसा की जाती है कि आपके पास अद्वितीय कुंजियाँ होनी चाहिए। ध्यान रखें कि प्राथमिक कुंजी पहले से ही एक अद्वितीय कुंजी है और प्राथमिक कुंजी में NULL मान नहीं बल्कि अद्वितीय कुंजी हो सकती है। प्राथमिक कुंजी को NULL मान निर्दिष्ट करने से त्रुटि हो सकती है, जैसे,
ERROR 1171 (42000): All parts of a PRIMARY KEY must be NOT NULL; if you need NULL in a key, use UNIQUE insteadस्लेव नोड्स के लिए, यह भी सामान्य है कि कुछ अवसरों में, प्राथमिक/अद्वितीय कुंजी टेबल पर मौजूद नहीं होती है, जो इसलिए टेबल संरचना की विसंगति है। आप इसे प्राप्त करने के लिए mysqldiff का उपयोग कर सकते हैं या आप mysqldump --no-data ... params कर सकते हैं और इसकी तालिका संरचना की तुलना करने के लिए एक अंतर चला सकते हैं और जांच सकते हैं कि कोई विसंगति है या नहीं।
डुप्लिकेट इंडेक्स के साथ टेबल स्कैन करें, फिर इसे छोड़ दें
डुप्लिकेट इंडेक्स भी प्रदर्शन में गिरावट का कारण बन सकते हैं, खासकर जब तालिका में बड़ी संख्या में रिकॉर्ड होते हैं। MySQL को क्वेरी को ऑप्टिमाइज़ करने के लिए कई प्रयास करने पड़ते हैं और जाँच करने के लिए अधिक क्वेरी प्लान निष्पादित करते हैं। इसमें बड़े सूचकांक वितरण या आंकड़ों को स्कैन करना शामिल है और यह प्रदर्शन ओवरहेड जोड़ता है क्योंकि यह स्मृति विवाद या उच्च I/O स्मृति उपयोग का कारण बन सकता है।
जब टेबल पर डुप्लीकेट इंडेक्स देखे जाते हैं तो प्रश्नों के लिए गिरावट बफर पूल को संतृप्त करने पर भी विशेषता होती है। यह MySQL के प्रदर्शन को भी प्रभावित कर सकता है जब चेकपॉइंट डिस्क में लेनदेन लॉग को फ्लश करता है। यह एक अवांछित सूचकांक के प्रसंस्करण और भंडारण के कारण है (जो वास्तव में उस तालिका के विशेष टेबलस्पेस में स्थान की बर्बादी है)। ध्यान दें कि डुप्लीकेट इंडेक्स टेबल स्पेस में भी स्टोर किए जाते हैं जिन्हें बफर पूल में भी स्टोर करना होता है।
नीचे दी गई तालिका पर एक नज़र डालें जिसमें कई डुप्लिकेट कुंजियाँ हैं:
root[test]#> show create table sbtest3\G
*************************** 1. row ***************************
Table: sbtest3
Create Table: CREATE TABLE `sbtest3` (
`id` int(10) unsigned NOT NULL AUTO_INCREMENT,
`k` int(10) unsigned NOT NULL DEFAULT '0',
`c` char(120) NOT NULL DEFAULT '',
`pad` char(60) NOT NULL DEFAULT '',
PRIMARY KEY (`id`),
KEY `k` (`k`,`pad`,`c`),
KEY `kcp2` (`id`,`k`,`c`,`pad`),
KEY `kcp` (`k`,`c`,`pad`),
KEY `pck` (`pad`,`c`,`id`,`k`)
) ENGINE=InnoDB AUTO_INCREMENT=2048561 DEFAULT CHARSET=latin1
1 row in set (0.00 sec)और इसका आकार 2.3GiB
हैroot[test]#> \! du -hs /var/lib/mysql/test/sbtest3.ibd
2.3G /var/lib/mysql/test/sbtest3.ibdआइए डुप्लीकेट सूचकांकों को छोड़ दें और बिना-ऑप परिवर्तन के तालिका का पुनर्निर्माण करें,
root[test]#> drop index kcp2 on sbtest3; drop index kcp on sbtest3 drop index pck on sbtest3;
Query OK, 0 rows affected (0.01 sec)
Records: 0 Duplicates: 0 Warnings: 0
Query OK, 0 rows affected (0.01 sec)
Records: 0 Duplicates: 0 Warnings: 0
Query OK, 0 rows affected (0.01 sec)
Records: 0 Duplicates: 0 Warnings: 0
root[test]#> alter table sbtest3 engine=innodb;
Query OK, 0 rows affected (28.23 sec)
Records: 0 Duplicates: 0 Warnings: 0
root[test]#> \! du -hs /var/lib/mysql/test/sbtest3.ibd
945M /var/lib/mysql/test/sbtest3.ibdयह टेबल स्पेस के पुराने आकार के ~59% तक को बचाने में सक्षम है जो वास्तव में बहुत बड़ा है।
डुप्लिकेट इंडेक्स निर्धारित करने के लिए, आप अपने लिए काम संभालने के लिए पीटी-डुप्लिकेट-चेकर का उपयोग कर सकते हैं।
अपना बफर पूल ट्यून करें
इस खंड के लिए मैं केवल InnoDB स्टोरेज इंजन की बात कर रहा हूं।
बफ़र पूल InnoDB कर्नेल स्थान के भीतर एक महत्वपूर्ण घटक है। यह वह जगह है जहां InnoDB एक्सेस किए जाने पर टेबल और इंडेक्स डेटा को कैश करता है। यह प्रसंस्करण को गति देता है क्योंकि बीटीआरईई का उपयोग करके अक्सर उपयोग किए जाने वाले डेटा को मेमोरी में कुशलता से संग्रहीत किया जा रहा है। उदाहरण के लिए, यदि आपके पास>=100GiB वाली कई टेबल हैं और उन तक भारी पहुंच है, तो हमारा सुझाव है कि आप 128GiB के आकार से शुरू होने वाली एक तेज़ वाष्पशील मेमोरी को सौंपें और बफर पूल को 80% भौतिक मेमोरी के साथ असाइन करना शुरू करें। 80% की कुशलता से निगरानी की जानी है। आप SHOW ENGINE INNODB STATUS \G का उपयोग कर सकते हैं या आप ClusterControl जैसे मॉनिटरिंग सॉफ़्टवेयर का लाभ उठा सकते हैं जो एक बढ़िया निगरानी प्रदान करता है जिसमें बफर पूल और इसके प्रासंगिक स्वास्थ्य मेट्रिक्स शामिल हैं। तदनुसार innodb_buffer_pool_instances वैरिएबल भी सेट करें। आप इसे 8 से बड़ा (डिफ़ॉल्ट अगर innodb_buffer_pool_size>=1GiB) सेट कर सकते हैं, जैसे कि यदि आवश्यक हो तो 16, 24, 32, या 64 या उच्चतर।
बफर पूल की निगरानी करते समय, आपको वैश्विक स्थिति चर Innodb_buffer_pool_pages_free की जांच करने की आवश्यकता होती है जो बफर पूल को समायोजित करने की आवश्यकता होने पर आपको विचार प्रदान करता है, या शायद विचार करें कि क्या अवांछित या डुप्लिकेट इंडेक्स भी हैं जो खपत करते हैं बफर। SHOW ENGINE INNODB STATUS \G बफ़र पूल जानकारी का अधिक विस्तृत पहलू भी प्रस्तुत करता है, जिसमें आपके द्वारा सेट किए गए innodb_buffer_pool_instances की संख्या के आधार पर इसके अलग-अलग बफ़र पूल शामिल हैं।
FULLTEXT अनुक्रमणिका का उपयोग करें (लेकिन केवल यदि लागू हो तो)
जैसे प्रश्नों का उपयोग करना,
SELECT bookid, page, context FROM books WHERE context like '%for dummies%';जिसमें संदर्भ एक स्ट्रिंग-प्रकार (चार, वर्चर, टेक्स्ट) कॉलम है, एक सुपर खराब क्वेरी का एक उदाहरण है! एक फिल्टर के साथ रिकॉर्ड की बड़ी सामग्री को खींचना जो लालची होना है, एक पूर्ण टेबल स्कैन के साथ समाप्त होता है, और यह सिर्फ पागल है। FULLTEXT अनुक्रमणिका का उपयोग करने पर विचार करें। FULLTEXT इंडेक्स में एक उल्टा इंडेक्स डिज़ाइन होता है। उल्टे अनुक्रमित शब्दों की एक सूची संग्रहीत करते हैं, और प्रत्येक शब्द के लिए, दस्तावेज़ों की एक सूची जिसमें शब्द दिखाई देता है। निकटता खोज का समर्थन करने के लिए, प्रत्येक शब्द की स्थिति की जानकारी को बाइट ऑफ़सेट के रूप में भी संग्रहीत किया जाता है।
डेटा खोजने या फ़िल्टर करने के लिए FULLTEXT का उपयोग करने के लिए, आपको MATCH() ...AGAINST सिंटैक्स के संयोजन का उपयोग करने की आवश्यकता है, न कि उपरोक्त क्वेरी की तरह। बेशक, आपको अपना FULLTEXT अनुक्रमणिका फ़ील्ड होने के लिए फ़ील्ड निर्दिष्ट करने की आवश्यकता है।
एक FULLTEXT अनुक्रमणिका बनाने के लिए, बस FULLTEXT को अपनी अनुक्रमणिका के रूप में निर्दिष्ट करें। नीचे दिया गया उदाहरण देखें:
root[minime]#> CREATE FULLTEXT INDEX aboutme_fts ON users_info(aboutme);
Query OK, 0 rows affected, 1 warning (0.49 sec)
Records: 0 Duplicates: 0 Warnings: 1
root[jbmrcd_date]#> show warnings;
+---------+------+--------------------------------------------------+
| Level | Code | Message |
+---------+------+--------------------------------------------------+
| Warning | 124 | InnoDB rebuilding table to add column FTS_DOC_ID |
+---------+------+--------------------------------------------------+
1 row in set (0.00 sec)हालांकि FULLTEXT इंडेक्स का उपयोग करने से कॉलम के अंदर बहुत बड़े संदर्भ में शब्दों की खोज करने पर लाभ मिल सकता है, लेकिन गलत तरीके से उपयोग किए जाने पर यह समस्याएँ भी पैदा करता है।
एक बड़ी तालिका के लिए FULLTEXT खोज करते समय जिसे लगातार एक्सेस किया जाता है (जहां कई क्लाइंट अनुरोध अलग-अलग, अद्वितीय कीवर्ड खोज रहे हैं) यह बहुत सीपीयू गहन हो सकता है।
कुछ ऐसे अवसर भी होते हैं जब FULLTEXT लागू नहीं होता है। यह बाहरी ब्लॉग पोस्ट देखें। हालांकि मैंने 8.0 के साथ यह कोशिश नहीं की है, लेकिन मुझे इसके लिए प्रासंगिक कोई बदलाव नहीं दिख रहा है। हमारा सुझाव है कि बड़े डेटा परिवेश की खोज के लिए FULLTEXT का उपयोग न करें, विशेष रूप से उच्च-ट्रैफ़िक तालिकाओं के लिए। अन्यथा, अन्य तकनीकों जैसे कि Apache Lucene, Apache Solr, tsearch2, या Sphinx का लाभ उठाने का प्रयास करें।
कॉलम में NULL का उपयोग करने से बचें
कॉलम जिनमें शून्य मान होते हैं, MySQL में पूरी तरह से ठीक हैं। लेकिन अगर आप इंडेक्स में शून्य मान वाले कॉलम का उपयोग कर रहे हैं, तो यह क्वेरी प्रदर्शन को प्रभावित कर सकता है क्योंकि ऑप्टिमाइज़र खराब इंडेक्स वितरण के कारण सही क्वेरी प्लान प्रदान नहीं कर सकता है। हालांकि, प्रश्नों को अनुकूलित करने के कुछ तरीके हैं जिनमें शून्य मान शामिल हैं लेकिन निश्चित रूप से, यदि यह आवश्यकताओं के अनुरूप है। कृपया नल ऑप्टिमाइज़ेशन के बारे में MySQL के दस्तावेज़ीकरण की जाँच करें। आप इस बाहरी पोस्ट को भी देख सकते हैं जो सहायक भी है।
अपनी स्कीमा टोपोलॉजी और टेबल संरचना को कुशलता से डिज़ाइन करें
कुछ हद तक, अपने डेटाबेस टेबल को 1NF (फर्स्ट नॉर्मल फॉर्म) से 3NF (थर्ड नॉर्मल फॉर्म) में नॉर्मल करने से आपको क्वेरी दक्षता के लिए कुछ लाभ मिलता है क्योंकि नॉर्मलाइज्ड टेबल्स अनावश्यक रिकॉर्ड से बचते हैं। आपकी तालिकाओं के लिए एक उचित योजना और डिज़ाइन बहुत महत्वपूर्ण है क्योंकि इस तरह आपने डेटा पुनर्प्राप्त या खींचा है और इनमें से प्रत्येक क्रिया में एक लागत होती है। सामान्यीकृत तालिकाओं के साथ, डेटाबेस का लक्ष्य यह सुनिश्चित करना है कि प्रत्येक तालिका में प्रत्येक गैर-कुंजी कॉलम सीधे कुंजी पर निर्भर है; पूरी कुंजी और कुंजी के अलावा कुछ नहीं। यदि यह लक्ष्य प्राप्त कर लिया जाता है, तो यह कम अतिरेक, कम विसंगतियों और बेहतर दक्षताओं के रूप में लाभों का भुगतान करता है।
अपनी तालिकाओं को सामान्य करने के कई लाभ हैं, लेकिन इसका मतलब यह नहीं है कि आपको अपनी सभी तालिकाओं को इस तरह से सामान्य करने की आवश्यकता है। आप स्टार स्कीमा का उपयोग करके अपने डेटाबेस के लिए एक डिज़ाइन लागू कर सकते हैं। Star Schema का उपयोग करके अपनी तालिकाओं को डिज़ाइन करने से सरल क्वेरी (जटिल क्रॉस जॉइन से बचें), रिपोर्टिंग के लिए डेटा पुनर्प्राप्त करना आसान है, प्रदर्शन लाभ प्रदान करता है क्योंकि यूनियनों या जटिल जॉइन, या तेज़ एकत्रीकरण का उपयोग करने की कोई आवश्यकता नहीं है। एक स्टार स्कीमा लागू करने के लिए सरल है, लेकिन आपको सावधानीपूर्वक योजना बनाने की आवश्यकता है क्योंकि जब आपकी तालिका बड़ी हो जाती है और रखरखाव की आवश्यकता होती है तो यह बड़ी समस्याएं और नुकसान पैदा कर सकती है। स्टार स्कीमा (और इसकी अंतर्निहित तालिकाएं) डेटा अखंडता के मुद्दों से ग्रस्त हैं, इसलिए आपको उच्च संभावना हो सकती है कि आपके डेटा का गुच्छा बेमानी है। यदि आपको लगता है कि यह तालिका स्थिर (संरचना और डिज़ाइन) होनी चाहिए और क्वेरी दक्षता का उपयोग करने के लिए डिज़ाइन की गई है, तो यह इस दृष्टिकोण के लिए एक आदर्श मामला है।
अपने डेटाबेस डिज़ाइन को मिलाना (जब तक आप यह निर्धारित करने और पहचानने में सक्षम हैं कि आपकी टेबल पर किस प्रकार का डेटा खींचा जाना है) बहुत महत्वपूर्ण है क्योंकि आप अधिक कुशल प्रश्नों के साथ-साथ लाभ उठा सकते हैं बैकअप, रखरखाव और पुनर्प्राप्ति के साथ DBA की सहायता करें।
स्थिर और पुराने डेटा से छुटकारा पाएं
हमने हाल ही में आपके डेटाबेस को क्लाउड में संग्रहीत करने के लिए कुछ सर्वोत्तम प्रक्रियाएं लिखी हैं। इसमें यह बताया गया है कि क्लाउड पर जाने से पहले आप डेटा संग्रह का लाभ कैसे उठा सकते हैं। तो पुराने डेटा से छुटकारा पाने या अपने स्थिर और पुराने डेटा को संग्रहीत करने से क्वेरी दक्षता में कैसे मदद मिलती है? जैसा कि मेरे पिछले ब्लॉग में कहा गया है, बड़ी तालिकाओं के लिए लाभ हैं जिन्हें लगातार संशोधित किया जाता है और नए डेटा के साथ डाला जाता है, टेबलस्पेस तेजी से बढ़ सकता है। MySQL और InnoDB कुशलता से प्रदर्शन करते हैं जब रिकॉर्ड या डेटा एक-दूसरे से सटे होते हैं और तालिका में इसकी अगली पंक्ति के लिए महत्व रखते हैं। मतलब, यदि आपके पास कोई पुराना रिकॉर्ड नहीं है जिसे अब उपयोग करने की आवश्यकता नहीं है, तो ऑप्टिमाइज़र को अधिक कुशल परिणाम देने वाले आँकड़ों में इसे शामिल करने की आवश्यकता नहीं है। समझ में आता है, है ना? और साथ ही, क्वेरी दक्षता न केवल एप्लिकेशन पक्ष पर है, बल्कि बैकअप करते समय और रखरखाव या विफलता पर इसकी दक्षता पर भी विचार करने की आवश्यकता है। उदाहरण के लिए, यदि आपके पास कोई खराब और लंबी क्वेरी है जो आपकी रखरखाव अवधि या विफलता को प्रभावित कर सकती है, तो यह एक समस्या हो सकती है।
आवश्यकतानुसार क्वेरी लॉगिंग सक्षम करें
अपने MySQL के धीमे क्वेरी लॉग को हमेशा अपनी कस्टम आवश्यकताओं के अनुसार सेट करें। यदि आप पेरकोना सर्वर का उपयोग कर रहे हैं, तो आप उनकी विस्तारित धीमी क्वेरी लॉगिंग का लाभ उठा सकते हैं। यह आपको कुछ चरों को कस्टम रूप से परिभाषित करने की अनुमति देता है। आप क्वेरी के प्रकारों को संयोजन में फ़िल्टर कर सकते हैं जैसे कि full_scan, full_join, tmp_table, आदि। आप वेरिएबल log_slow_rate_type, और कई अन्य के माध्यम से धीमी क्वेरी लॉगिंग की दर भी निर्धारित कर सकते हैं।
MySQL में क्वेरी लॉगिंग को सक्षम करने का महत्व (जैसे धीमी क्वेरी) आपके प्रश्नों का निरीक्षण करने के लिए फायदेमंद है ताकि आप अपनी आवश्यकताओं के अनुरूप कुछ चरों को समायोजित करके अपने MySQL को अनुकूलित या ट्यून कर सकें। धीमी क्वेरी लॉग को सक्षम करने के लिए, सुनिश्चित करें कि ये चर सेटअप हैं:
- long_query_time - क्वेरी में कितना समय लग सकता है, इसके लिए सही मान असाइन करें। यदि क्वेरी में 10 सेकंड से अधिक समय लगता है (डिफ़ॉल्ट), तो यह आपके द्वारा असाइन की गई धीमी क्वेरी लॉग फ़ाइल में आ जाएगी।
- slow_query_log - इसे सक्षम करने के लिए, इसे 1 पर सेट करें।
- slow_query_log_file - यह आपकी धीमी क्वेरी लॉग फ़ाइल का गंतव्य पथ है।
स्लो क्वेरी लॉग क्वेरी विश्लेषण और खराब क्वेरी का निदान करने के लिए बहुत मददगार है जो स्टॉल, स्लेव देरी, लंबे समय तक चलने वाली क्वेरी, मेमोरी या सीपीयू गहन, या यहां तक कि सर्वर को क्रैश करने का कारण बनता है। यदि आप पीटी-क्वेरी-डाइजेस्ट या पीटी-इंडेक्स-उपयोग का उपयोग करते हैं, तो इन प्रश्नों को समान रूप से रिपोर्ट करने के लिए अपने स्रोत लक्ष्य के रूप में धीमी क्वेरी लॉग फ़ाइल का उपयोग करें।
निष्कर्ष
हमने इस ब्लॉग में डेटाबेस क्वेरी दक्षता को अधिकतम करने के लिए उपयोग किए जाने वाले कुछ तरीकों पर चर्चा की है। इस अगले भाग में हम और भी अधिक कारकों पर चर्चा करेंगे जो आपको प्रदर्शन को अधिकतम करने में मदद कर सकते हैं। बने रहें!
