SQL Query Optimization Techniques

افلاطون کے ذریعہ دوبارہ شائع کیا گیا۔

فالونگ: 0

SQL استفسار کی اصلاح کی تکنیک
مصنف کی طرف سے تصویر

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

ای کامرس پلیٹ فارمز یا بینکنگ سسٹم جیسے لاکھوں ریکارڈز کے ساتھ بڑی ایپلی کیشنز میں ایک بہتر سوال لکھنا ناگزیر ہے۔ فرض کریں کہ آپ ایک ای کامرس کمپنی کے مالک ہیں جس میں ایک ملین سے زیادہ پروڈکٹس ہیں، اور ایک گاہک کسی پروڈکٹ کو تلاش کرنا چاہتا ہے۔ اگر آپ نے بیک اینڈ میں جو سوال لکھا ہے اسے ڈیٹا بیس سے اس پروڈکٹ کو لانے میں ایک منٹ سے زیادہ وقت لگے تو کیا ہوگا؟ کیا آپ کو لگتا ہے کہ گاہک آپ کی ویب سائٹ سے مصنوعات خریدیں گے؟

آپ کو SQL استفسار کی اصلاح کی اہمیت کو سمجھنا ہوگا۔ اس ٹیوٹوریل میں، میں آپ کو آپ کے ایس کیو ایل کے سوالات کو بہتر بنانے اور انہیں تیزی سے انجام دینے کے لیے کچھ تجاویز اور چالیں دکھاؤں گا۔ بنیادی پیشگی شرط یہ ہے کہ آپ کے پاس SQL کا بنیادی علم ہونا ضروری ہے۔

یہ چیک کرنے کے لیے کہ آیا کوئی مخصوص عنصر ٹیبل میں موجود ہے، استعمال کریں۔ EXIST() مطلوبہ الفاظ کی بجائے COUNT() استفسار کو زیادہ بہتر انداز میں چلائے گا۔

کا استعمال کرتے ہوئے COUNT()، استفسار کو اس مخصوص عنصر کے تمام واقعات کو شمار کرنے کی ضرورت ہے جو ڈیٹا بیس کے وسیع ہونے پر ناکارہ ہوسکتی ہے۔ دوسری جانب، EXIST() اس عنصر کی صرف پہلی موجودگی کی جانچ کرے گا اور پھر جب اسے پہلی بار مل جائے گا تو رک جائے گا۔ اس سے وقت کی بہت بچت ہوتی ہے۔

اس کے علاوہ، آپ صرف یہ جاننے میں دلچسپی رکھتے ہیں کہ آیا کوئی خاص عنصر موجود ہے یا نہیں۔ آپ کو واقعات کی تعداد معلوم کرنے میں دلچسپی نہیں ہے۔ اس لیے بھی EXIST() بہتر ہے.

SELECT EXISTS( SELECT * FROM table WHERE myColumn = 'val' );

اوپر والا سوال واپس آجائے گا۔ 1 اگر کم از کم ایک ٹیبل قطار میں ایک اندراج ہے جہاں ایک کالم کا نام ہے۔ myColumn کے برابر قدر ہے۔ ویل. دوسری صورت میں، یہ واپس آ جائے گا 0.

دونوں char اور varchar ڈیٹا کی قسمیں ٹیبل میں کریکٹر سٹرنگز کو ذخیرہ کرنے کے لیے استعمال ہوتی ہیں۔ لیکن varchar سے کہیں زیادہ میموری موثر ہے۔ char.

چار ڈیٹا ٹائپ صرف مقررہ لمبائی کی کریکٹر سٹرنگ کو اسٹور کر سکتا ہے۔ اگر سٹرنگ کی لمبائی مقررہ لمبائی سے کم ہے، تو یہ خالی جگہوں کو پیڈ کرے گا تاکہ اس کی لمبائی سیٹ کی لمبائی کے برابر ہو جائے۔ یہ پیڈنگ میں غیر ضروری طور پر میموری کو ضائع کردے گا۔ مثال کے طور پر،CHAR(100) 100 بائٹس میموری لے گا یہاں تک کہ اگر ایک بھی کریکٹر محفوظ ہے۔

دوسری طرف، varchar ڈیٹا ٹائپ متغیر کی لمبائی کی کریکٹر سٹرنگ کو ذخیرہ کرتا ہے جس کی لمبائی زیادہ سے زیادہ مخصوص لمبائی سے کم ہوتی ہے۔ یہ خالی جگہوں کو پیڈ نہیں کرتا ہے اور صرف اسٹرنگ کی اصل لمبائی کے برابر میموری لیتا ہے۔ مثال کے طور پر، VARCHAR(100) ایک کریکٹر کو اسٹور کرتے وقت صرف 1 بائٹ میموری لیتا ہے۔

CREATE TABLE myTable ( id INT PRIMARY KEY, charCol CHAR(10), varcharCol VARCHAR(10)
);

مندرجہ بالا مثال میں، ایک میز myTable دو کالموں کے ساتھ بنایا گیا ہے، charCol اور varcharCol بالترتیب چار اور ورچار ڈیٹا ٹائپس کا ہونا۔ charCol ہمیشہ 10 بائٹس میموری لے گا۔ اس کے برعکس میں، varcharCol اس میں ذخیرہ شدہ کریکٹر سٹرنگ کے اصل سائز کے برابر میموری لیتا ہے۔

ہمیں SQL استفسار کو بہتر بنانے کے لیے WHERE شق کے اندر ذیلی سوالات کے استعمال سے گریز کرنا چاہیے۔ چونکہ ذیلی سوالات مہنگے اور مشکل ہوسکتے ہیں جب وہ بڑی تعداد میں قطاریں واپس کرتے ہیں۔

ذیلی استفسار استعمال کرنے کے بجائے، آپ جوائن آپریشن کا استعمال کر کے یا متعلقہ ذیلی سوال لکھ کر وہی نتیجہ حاصل کر سکتے ہیں۔ ایک متعلقہ ذیلی استفسار ایک ذیلی استفسار ہے جس میں اندرونی استفسار بیرونی استفسار پر منحصر ہوتا ہے۔ اور وہ غیر متعلقہ ذیلی سوالات کے مقابلے میں بہت موثر ہیں۔

دونوں کے درمیان فرق کو سمجھنے کے لیے ذیل میں ایک مثال ہے۔

# Using a subquery
SELECT * FROM orders WHERE customer_id IN ( SELECT id FROM customers WHERE country = 'INDIA' ); # Using a join operation
SELECT orders.* FROM orders JOIN customers ON orders.customer_id = customers.id WHERE customers.country = 'INDIA';

پہلی مثال میں، ذیلی استفسار پہلے ان تمام کسٹمر آئی ڈیز کو اکٹھا کرتا ہے جو انڈیا سے تعلق رکھتے ہیں، اور پھر بیرونی استفسار کو منتخب کسٹمر آئی ڈیز کے تمام آرڈرز مل جائیں گے۔ اور دوسری مثال میں، ہم نے شامل ہو کر وہی نتیجہ حاصل کیا ہے۔ customers اور orders ٹیبلز اور پھر صرف ان آرڈرز کا انتخاب کریں جہاں صارفین کا تعلق ہندوستان سے ہو۔

اس طرح، ہم WHERE شق کے اندر ذیلی سوالات کے استعمال سے گریز کرکے اور انہیں پڑھنے اور سمجھنے میں آسان بنا کر استفسار کو بہتر بنا سکتے ہیں۔

کا اطلاق JOIN بڑے ٹیبل سے چھوٹی ٹیبل تک آپریشن ایک عام ایس کیو ایل آپٹیمائزیشن تکنیک ہے۔ کیونکہ ایک بڑے ٹیبل سے چھوٹی ٹیبل میں شامل ہونے سے آپ کے استفسار کو تیزی سے عمل میں لایا جائے گا۔ اگر ہم درخواست دیتے ہیں a JOIN ایک چھوٹی ٹیبل سے بڑی ٹیبل تک آپریشن، ہمارے ایس کیو ایل انجن کو قطاروں کے ملاپ کے لیے بڑے ٹیبل میں تلاش کرنا پڑتا ہے۔ یہ زیادہ وسائل اور وقت طلب ہے۔ لیکن دوسری طرف، اگر JOIN ایک بڑی ٹیبل سے چھوٹی ٹیبل پر لاگو کیا جاتا ہے، پھر ایس کیو ایل انجن کو قطاروں کو ملانے کے لیے ایک چھوٹی ٹیبل میں تلاش کرنا پڑتا ہے۔

آپ کی بہتر تفہیم کے لیے یہاں ایک مثال ہے۔

# Order table is larger than the Customer table # Join from a larger table to a smaller table
SELECT * FROM Order JOIN Customer ON Customer.id = Order.id # Join from a smaller table to a larger table
SELECT * FROM Customer JOIN Order ON Customer.id = Order.id

کے برعکس LIKE شق، regexp_like پیٹرن کی تلاش کے لیے بھی استعمال کیا جاتا ہے۔ دی LIKE شق ایک بنیادی پیٹرن سے مماثل آپریٹر ہے جو صرف بنیادی کام انجام دے سکتا ہے جیسے _ or %، جو بالترتیب کسی ایک حرف یا حروف کی تعداد سے ملنے کے لیے استعمال ہوتے ہیں۔ دی LIKE شق کو خاص پیٹرن تلاش کرنے کے لیے مکمل ڈیٹا بیس کو اسکین کرنا چاہیے، جو بڑی میزوں کے لیے سست ہے۔

دوسری طرف، regexp_like پیٹرن تلاش کرنے کی ایک زیادہ موثر، بہتر اور طاقتور تکنیک ہے۔ یہ کریکٹر سٹرنگ میں مخصوص پیٹرن تلاش کرنے کے لیے زیادہ پیچیدہ ریگولر ایکسپریشنز کا استعمال کرتا ہے۔ یہ ریگولر ایکسپریشنز سادہ وائلڈ کارڈ مماثلت سے زیادہ مخصوص ہیں کیونکہ یہ آپ کو بالکل وہی پیٹرن تلاش کرنے کی اجازت دیتے ہیں جو ہم تلاش کر رہے ہیں۔ اس کی وجہ سے، جس ڈیٹا کو تلاش کرنے کی ضرورت ہے اس کی مقدار کم ہو جاتی ہے، اور استفسار تیزی سے ہوتا ہے۔

براہ مہربانی یاد رکھیں regexp_like ہو سکتا ہے کہ تمام ڈیٹا بیس مینجمنٹ سسٹم میں موجود نہ ہوں۔ اس کی نحو اور فعالیت دوسرے نظاموں میں مختلف ہو سکتی ہے۔

آپ کی بہتر تفہیم کے لیے یہاں ایک مثال ہے۔

# Query using the LIKE clause
SELECT * FROM mytable WHERE ( name LIKE 'A%' OR name LIKE 'B%' ); # Query using regexp_like clause
SELECT * FROM mytable WHERE regexp_like(name, '^[AB].*');

مندرجہ بالا سوالات ان عناصر کو تلاش کرنے کے لیے استعمال کیے جاتے ہیں جن کا نام A یا B سے شروع ہوتا ہے۔ پہلی مثال میں، LIKE A یا B سے شروع ہونے والے تمام ناموں کو تلاش کرنے کے لیے استعمال کیا جاتا ہے۔ A% اس کا مطلب ہے کہ پہلا حرف A ہے۔ اس کے بعد، حروف کی کوئی بھی تعداد موجود ہو سکتی ہے۔ دوسری مثال میں، regexp_like استعمال کیا جاتا ہے. اندر ^[AB], ^ نمائندگی کرتا ہے کہ علامت سٹرنگ کے شروع میں مماثل ہوگی، [AB] نمائندگی کرتا ہے کہ ابتدائی کردار A یا B ہو سکتا ہے، اور .* اس کے بعد کے تمام کرداروں کی نمائندگی کرتا ہے۔

کا استعمال کرتے ہوئے regexp_like، ڈیٹا بیس تیزی سے ان قطاروں کو فلٹر کر سکتا ہے جو پیٹرن سے میل نہیں کھاتی ہیں، کارکردگی کو بہتر بنا کر اور وسائل کے استعمال کو کم کر سکتی ہے۔

اس مضمون میں، ہم نے SQL استفسار کو بہتر بنانے کے مختلف طریقوں اور تجاویز پر تبادلہ خیال کیا ہے۔ یہ مضمون آپ کو ایک واضح تفہیم فراہم کرتا ہے کہ کس طرح موثر SQL سوالات لکھیں اور ان کو بہتر بنانے کی اہمیت۔ استفسارات کو بہتر بنانے کے اور بھی بہت سے طریقے ہیں، جیسے حروف کی بجائے عددی اقدار کے استعمال کو ترجیح دینا یا یونین کے بجائے Union All کا استعمال کرنا جب آپ کے ٹیبل میں ڈپلیکیٹس نہ ہوں وغیرہ۔

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