MySQL डेटाबेस परफ़ॉर्मेंस ट्यूनिंग की मूल बातें

Linux VPS या क्लाउड सर्वर पर MySQL 8.0 को ट्यून करने की एक व्यावहारिक, चरण-दर-चरण गाइड: पहले slow query log से मापें, InnoDB बफ़र पूल का सही आकार तय करें, EXPLAIN आउटपुट पढ़ें, और सही इंडेक्स जोड़ें।

MySQL डेटाबेस परफ़ॉर्मेंस ट्यूनिंग की मूल बातें

धीमा डेटाबेस किसी एप्लिकेशन के धीमे होने का सबसे आम कारण है। अपने सर्वर को स्केल करने या कोड फिर से लिखने से पहले, कुछ घंटों की व्यवस्थित MySQL ट्यूनिंग अक्सर खोई हुई अधिकांश परफ़ॉर्मेंस को वापस ला देती है। यह गाइड MySQL 8.0 चलाने वाले एक सामान्य Linux VPS या क्लाउड सर्वर पर मूल बातों से होकर गुज़रती है: मापें, मेमोरी का आकार तय करें, क्वेरी प्लान पढ़ें, और सही इंडेक्स जोड़ें।

ये चरण किसी भी मानक MySQL 8.0 इंस्टॉल पर लागू होते हैं — इनमें Skyline Cloud VPS या क्लाउड सर्वर पर इन-किंगडम होस्ट किए गए डेटाबेस भी शामिल हैं, जहाँ आपके डेटा को सऊदी अरब में रेज़िडेंट रखना PDPL और NCA अनुपालन में मदद करता है।

पूर्वापेक्षाएँ

• MySQL 8.0 इंस्टॉल किया हुआ एक Linux सर्वर (Ubuntu 22.04/24.04, Debian, या RHEL परिवार)।
• sudo एक्सेस वाला एक उपयोगकर्ता और प्रशासनिक विशेषाधिकारों वाला एक MySQL खाता।
• एक वास्तविक या प्रतिनिधि वर्कलोड — एक निष्क्रिय डेटाबेस के विरुद्ध ट्यूनिंग आपको कुछ नहीं बताती।

हमेशा एक बार में एक ही वेरिएबल बदलें और फिर से मापें। माप के बिना ट्यूनिंग केवल अनुमान लगाना है।

चरण 1 — पहले Slow Query Log से मापें

जिसे आप मापते नहीं, उसे आप ट्यून नहीं कर सकते। slow query log हर उस स्टेटमेंट को रिकॉर्ड करता है जो एक समय सीमा से अधिक लेता है, जो आपके सबसे बड़े अपराधियों को खोजने का सबसे तेज़ तरीका है।

इसे रनटाइम पर सक्षम करें (किसी रीस्टार्ट की आवश्यकता नहीं):

SET GLOBAL slow_query_log = 'ON';
SET GLOBAL long_query_time = 1;            -- log queries slower than 1 second
SET GLOBAL log_queries_not_using_indexes = 'ON';

इसे स्थायी बनाने के लिए, इसे अपने MySQL कॉन्फ़िग में जोड़ें (Ubuntu/Debian पर /etc/mysql/mysql.conf.d/mysqld.cnf, या RHEL पर /etc/my.cnf):

[mysqld]
slow_query_log = 1
slow_query_log_file = /var/log/mysql/mysql-slow.log
long_query_time = 1
log_queries_not_using_indexes = 1

एक प्रतिनिधि वर्कलोड को चलने दें, फिर लॉग का विश्लेषण करें। Percona Toolkit का pt-query-digest एक समान क्वेरीज़ को फ़िंगरप्रिंट के अनुसार समूहित करता है और उन्हें कुल खपत समय के अनुसार रैंक करता है:

sudo apt install percona-toolkit   # Debian/Ubuntu
pt-query-digest /var/log/mysql/mysql-slow.log | less

रिपोर्ट के शीर्ष पर मौजूद क्वेरीज़ पर ध्यान दें — वे जिनका कुल निष्पादन समय सबसे अधिक है, न कि केवल सबसे अधिक सिंगल-रन समय वाली। एक मिनट में 10,000 बार चलने वाली क्वेरी को ऑप्टिमाइज़ करना, रात में एक बार चलने वाली क्वेरी को ऑप्टिमाइज़ करने से बेहतर है।

चरण 2 — InnoDB बफ़र पूल का आकार तय करें

InnoDB डिफ़ॉल्ट स्टोरेज इंजन है, और इसका बफ़र पूल टेबल और इंडेक्स डेटा को RAM में कैश करता है। यदि आपका वर्किंग सेट बफ़र पूल में समा जाता है, तो MySQL अधिकांश रीड्स को डिस्क के बजाय मेमोरी से सर्व करता है — आमतौर पर यह सबसे बड़ी जीत होती है।

अपना वर्तमान आकार और हिट रेशियो जाँचें:

SHOW VARIABLES LIKE 'innodb_buffer_pool_size';

SELECT
  (1 - (SELECT VARIABLE_VALUE FROM performance_schema.global_status
        WHERE VARIABLE_NAME = 'Innodb_buffer_pool_reads')
      / NULLIF((SELECT VARIABLE_VALUE FROM performance_schema.global_status
        WHERE VARIABLE_NAME = 'Innodb_buffer_pool_read_requests'), 0)) * 100
  AS hit_ratio_pct;

99% या उससे अधिक के हिट रेशियो का लक्ष्य रखें। Oracle के दस्तावेज़ीकरण के अनुसार, एक समर्पित डेटाबेस सर्वर पर बफ़र पूल को कुल RAM का 50–75% सेट करें, OS और MySQL के अन्य बफ़र्स के लिए जगह छोड़ें (InnoDB स्वयं कॉन्फ़िगर किए गए आकार से लगभग 10% अधिक आरक्षित करता है)। एक छोटे साझा सर्वर पर, 50% के क़रीब रहें और OS के लिए कम से कम 1–2 GB छोड़ें।

8 GB समर्पित सर्वर के लिए, लगभग 5–6 GB एक उचित शुरुआती बिंदु है:

[mysqld]
innodb_buffer_pool_size = 5G

MySQL को रीस्टार्ट करें और वर्कलोड द्वारा कैश को गर्म करने के बाद हिट रेशियो फिर से जाँचें। इसे अधिक बड़ा न करें: यदि बफ़र पूल और अन्य प्रक्रियाएँ RAM से अधिक हो जाती हैं, तो OS डिस्क पर स्वैप करता है और परफ़ॉर्मेंस ढह जाती है।

चरण 3 — EXPLAIN के साथ क्वेरी प्लान पढ़ें

एक बार जब आप जान जाते हैं कि कौन-सी क्वेरीज़ धीमी हैं, तो पता लगाएँ कि क्यों। EXPLAIN दिखाता है कि MySQL किसी स्टेटमेंट को कैसे निष्पादित करने का इरादा रखता है:

EXPLAIN SELECT * FROM orders WHERE customer_id = 42 AND status = 'shipped';

सबसे महत्वपूर्ण कॉलम:

MySQL 8.0 में आप EXPLAIN ANALYZE के साथ और आगे जा सकते हैं, जो वास्तव में क्वेरी चलाता है और अनुमानों के साथ-साथ वास्तविक टाइमिंग की रिपोर्ट करता है:

EXPLAIN ANALYZE SELECT * FROM orders WHERE customer_id = 42 AND status = 'shipped';

यह पुष्टि करने का सबसे विश्वसनीय तरीका है कि किसी इंडेक्स बदलाव से वास्तव में मदद मिली या नहीं।

चरण 4 — सही इंडेक्स जोड़ें

किसी बड़ी टेबल पर पूर्ण टेबल स्कैन (type: ALL) धीमी क्वेरीज़ का क्लासिक कारण है। WHERE, JOIN, और ORDER BY क्लॉज़ में उपयोग किए गए कॉलमों पर एक इंडेक्स जोड़ें।

ऊपर दी गई क्वेरी के लिए, दोनों फ़िल्टर किए गए कॉलमों को कवर करने वाला एक कंपोज़िट इंडेक्स MySQL को सीधे मिलान वाली पंक्तियों तक पहुँचने देता है:

CREATE INDEX idx_orders_customer_status
  ON orders (customer_id, status);

कॉलम क्रम मायने रखता है: सबसे चयनात्मक कॉलम — या वह जो समानता मिलान के लिए उपयोग होता है — को पहले रखें। एक कंपोज़िट इंडेक्स उन क्वेरीज़ की भी सेवा करता है जो केवल अग्रणी कॉलम (customer_id) पर फ़िल्टर करती हैं, इसलिए आपको शायद ही कभी इसके लिए एक अलग सिंगल-कॉलम इंडेक्स की आवश्यकता होती है।

EXPLAIN ANALYZE को फिर से चलाकर पुष्टि करें कि type में सुधार हुआ (उदाहरण के लिए ALL से ref तक) और rows तेज़ी से घटा।

इंडेक्स मुफ़्त नहीं होते — वे डिस्क स्थान खर्च करते हैं और राइट्स (INSERT/UPDATE/DELETE) को धीमा कर देते हैं, क्योंकि प्रत्येक इंडेक्स को बनाए रखना पड़ता है। सोच-समझकर इंडेक्स करें, और उन अप्रयुक्त इंडेक्सों को हटाएँ जिन्हें आप sys.schema_unused_indexes व्यू के माध्यम से पहचान सकते हैं:

SELECT * FROM sys.schema_unused_indexes;

चरण 5 — सत्यापित करें, फिर दोहराएँ

ट्यूनिंग एक लूप है, एक बार का काम नहीं। प्रत्येक बदलाव के बाद:

1. प्रभावित क्वेरी को EXPLAIN ANALYZE के साथ फिर से चलाएँ और टाइमिंग की तुलना करें।
2. slow query log को फिर से चलने दें और उसे फिर से डाइजेस्ट करें।
3. पुष्टि करें कि बफ़र पूल हिट रेशियो ऊँचा बना रहा।

किसी भी ऐसे बदलाव को वापस ले लें जिससे मदद न मिली हो। आपने क्या बदला और क्यों, इस पर नोट्स रखें — भविष्य का आप वर्तमान के आप का आभारी रहेगा।

आम गलतियाँ

• किसी एकल क्वेरी को अलगाव में ट्यून करना। कुल प्रभाव (आवृत्ति × लागत) के अनुसार ऑप्टिमाइज़ करें, जिसे slow log डाइजेस्ट उजागर करता है।
• ब्लॉग से my.cnf मान कॉपी करना। बफ़र पूल का आकार आपकी RAM और डेटासेट पर निर्भर करता है। मापें, कॉपी न करें।
• इंडेक्स किए गए कॉलमों को फ़ंक्शनों में लपेटना। WHERE DATE(created_at) = '2026-06-08' created_at पर इंडेक्स का उपयोग नहीं कर सकता; इसे एक रेंज के रूप में फिर से लिखें: WHERE created_at >= '2026-06-08' AND created_at < '2026-06-09'।
• चौड़ी टेबलों पर SELECT *। केवल वही कॉलम लाएँ जिनकी आपको आवश्यकता है ताकि MySQL कवरिंग इंडेक्सों का उपयोग कर सके।

निष्कर्ष

MySQL परफ़ॉर्मेंस ट्यूनिंग व्यवस्थित है, जादुई नहीं: slow query log से मापें, InnoDB को पर्याप्त RAM दें, EXPLAIN ANALYZE के साथ क्वेरी प्लान पढ़ें, और सोच-समझकर इंडेक्स जोड़ें। ये चार मूल बातें किसी भी हार्डवेयर अपग्रेड की आवश्यकता से पहले अधिकांश वास्तविक-दुनिया की मंदी को हल कर देती हैं।

ऐसे वर्कलोड के लिए जिन्हें स्केलिंग, अनुमानित लेटेंसी, या अरबी-भाषी स्थानीय समर्थन की आवश्यकता है, अपने डेटाबेस को इन-किंगडम होस्ट करें। Skyline Cloud VPS और क्लाउड सर्वर का अन्वेषण करें, पूर्ण स्टैक के लिए उन्हें बिज़नेस ईमेल होस्टिंग के साथ जोड़ें, और मिनटों में एक ट्यून किए गए MySQL सर्वर को डिप्लॉय करने के लिए अपना Skyline Cloud खाता बनाएँ।