MySQL ڈیٹابیس پرفارمنس ٹیوننگ کی بنیادی باتیں

Linux VPS یا کلاؤڈ سرور پر MySQL 8.0 کو ٹیون کرنے کی ایک عملی، مرحلہ وار رہنمائی: پہلے سلو کوئری لاگ کے ذریعے پیمائش کریں، InnoDB بفر پول کا درست سائز مقرر کریں، EXPLAIN کا آؤٹ پٹ پڑھیں، اور درست انڈیکسز شامل کریں۔

MySQL ڈیٹابیس پرفارمنس ٹیوننگ کی بنیادی باتیں

سست ڈیٹابیس کسی ایپلیکیشن کے سست ہونے کی سب سے عام وجہ ہے۔ اپنے سرور کو اپ گریڈ کرنے یا کوڈ دوبارہ لکھنے سے پہلے، چند گھنٹوں کی منظم MySQL ٹیوننگ اکثر ضائع شدہ کارکردگی کا بیشتر حصہ بحال کر دیتی ہے۔ یہ رہنمائی MySQL 8.0 چلانے والے ایک عام Linux VPS یا کلاؤڈ سرور پر بنیادی باتوں سے گزرتی ہے: پیمائش کریں، میموری کا سائز مقرر کریں، کوئری پلانز پڑھیں، اور درست انڈیکسز شامل کریں۔

یہ اقدامات کسی بھی معیاری MySQL 8.0 انسٹالیشن پر لاگو ہوتے ہیں — بشمول وہ ڈیٹابیسز جو سلطنت کے اندر Skyline Cloud VPS یا کلاؤڈ سرور پر میزبان ہوں، جہاں آپ کے ڈیٹا کا سعودی عرب میں مقیم رہنا PDPL اور NCA کی تعمیل میں مدد دیتا ہے۔

پیشگی شرائط

• ایک Linux سرور (Ubuntu 22.04/24.04، Debian، یا RHEL فیملی) جس پر MySQL 8.0 انسٹال ہو۔
• ایک ایسا صارف جس کے پاس sudo رسائی ہو اور ایک MySQL اکاؤنٹ جس کے پاس انتظامی مراعات ہوں۔
• ایک حقیقی یا نمائندہ ورک لوڈ — ایک بے کار (idle) ڈیٹابیس کے خلاف ٹیوننگ آپ کو کچھ نہیں بتاتی۔

ہمیشہ ایک وقت میں ایک ہی متغیر تبدیل کریں اور دوبارہ پیمائش کریں۔ پیمائش کے بغیر ٹیوننگ محض اندازہ لگانا ہے۔

مرحلہ 1 — پہلے سلو کوئری لاگ کے ساتھ پیمائش کریں

آپ اس چیز کو ٹیون نہیں کر سکتے جس کی آپ پیمائش نہیں کرتے۔ سلو کوئری لاگ ہر اس اسٹیٹمنٹ کو ریکارڈ کرتا ہے جو ایک مقررہ وقت کی حد سے تجاوز کرتی ہے، جو آپ کے بدترین مجرموں کو تلاش کرنے کا تیز ترین طریقہ ہے۔

اسے رن ٹائم پر فعال کریں (ری اسٹارٹ کی ضرورت نہیں):

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);

کالم کی ترتیب اہمیت رکھتی ہے: سب سے زیادہ منتخب (selective) کالم — یا وہ جو مساوات کی مماثلت کے لیے استعمال ہوتا ہے — کو پہلے رکھیں۔ ایک کمپوزٹ انڈیکس ان کوئریز کی بھی خدمت کرتا ہے جو صرف لیڈنگ کالم (customer_id) پر فلٹر کرتی ہیں، لہٰذا آپ کو اس کے لیے شاذ و نادر ہی الگ سنگل کالم انڈیکس کی ضرورت پڑتی ہے۔

EXPLAIN ANALYZE دوبارہ چلائیں تاکہ تصدیق ہو جائے کہ type بہتر ہوا (مثلاً ALL سے ref تک) اور یہ کہ rows تیزی سے کم ہوا۔

انڈیکسز مفت نہیں ہیں — یہ ڈسک کی جگہ استعمال کرتے ہیں اور رائٹس (INSERT/UPDATE/DELETE) کو سست کر دیتے ہیں، کیونکہ ہر انڈیکس کو برقرار رکھنا پڑتا ہے۔ سوچ سمجھ کر انڈیکس کریں، اور غیر استعمال شدہ انڈیکسز کو ہٹا دیں جنہیں آپ sys.schema_unused_indexes ویو کے ذریعے شناخت کر سکتے ہیں:

SELECT * FROM sys.schema_unused_indexes;

مرحلہ 5 — تصدیق کریں، پھر دہرائیں

ٹیوننگ ایک تکراری عمل (loop) ہے، ایک بار کا کام نہیں۔ ہر تبدیلی کے بعد:

1. متاثرہ کوئری کو EXPLAIN ANALYZE کے ساتھ دوبارہ چلائیں اور اوقات کا موازنہ کریں۔
2. سلو کوئری لاگ کو دوبارہ چلنے دیں اور اسے دوبارہ ڈائجسٹ کریں۔
3. تصدیق کریں کہ بفر پول ہٹ ریشو بلند رہا۔

کوئی بھی ایسی تبدیلی واپس لے لیں جس سے مدد نہ ملی ہو۔ نوٹس رکھیں کہ آپ نے کیا تبدیل کیا اور کیوں — مستقبل کا آپ موجودہ آپ کا شکریہ ادا کرے گا۔

عام نقصانات

• کسی ایک کوئری کو الگ تھلگ کر کے ٹیون کرنا۔ مجموعی اثر (تعدد × لاگت) کے لحاظ سے بہتر بنائیں، جسے سلو لاگ ڈائجسٹ آشکار کرتا ہے۔
• بلاگز سے 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 پرفارمنس ٹیوننگ منظم ہے، جادوئی نہیں: سلو کوئری لاگ کے ساتھ پیمائش کریں، InnoDB کو کافی RAM دیں، EXPLAIN ANALYZE کے ساتھ کوئری پلانز پڑھیں، اور سوچ سمجھ کر انڈیکسز شامل کریں۔ یہ چار بنیادی باتیں کسی بھی ہارڈویئر اپ گریڈ کی ضرورت سے پہلے حقیقی دنیا کی اکثر سست رفتاریوں کو حل کر دیتی ہیں۔

ایسے ورک لوڈز کے لیے جنہیں اسکیلنگ، قابلِ پیش گوئی لیٹنسی، یا عربی بولنے والی مقامی سپورٹ درکار ہے، اپنے ڈیٹابیسز سلطنت کے اندر میزبان کریں۔ Skyline Cloud VPS اور کلاؤڈ سرورز دریافت کریں، انہیں ایک مکمل اسٹیک کے لیے بزنس ای میل ہوسٹنگ کے ساتھ جوڑیں، اور چند منٹوں میں ایک ٹیون شدہ MySQL سرور تعینات کرنے کے لیے اپنا Skyline Cloud اکاؤنٹ بنائیں۔